Moshe Sambol, VP of Customer Solutions bei Lightrun – Interview-Serie

Moshe Sambol, VP of Customer Solutions bei Lightrun – bringt mehr als zwei Jahrzehnte Erfahrung in den Bereichen Software-Engineering, Architektur, Cloud-Infrastruktur und kundenorientierte technische Führung mit. Bevor er 2022 zu Lightrun kam, verbrachte er fast ein Jahrzehnt bei Google, wo er verschiedene Führungspositionen innehatte, darunter Cloud Customer Engineering Manager, und half Organisationen dabei, Google-Cloud-Technologien zu adoptieren und zu skalieren. Zu Beginn seiner Karriere hatte Sambol Ingenieur- und Entwicklungsführungsrollen bei Oracle, Sun Microsystems, BMC Software und JPMorgan Chase inne. Bei Lightrun leitete er zunächst die globale Solution Engineering und wurde dann zum VP of Customer Solutions ernannt, wo er sich darauf konzentriert, Kunden dabei zu helfen, die Runtime-Insights-Technologie des Unternehmens zu adoptieren und ihre Fähigkeiten in messbare Geschäfts- und Entwickler-Produktivitätsgewinne umzusetzen.

Lightrun ist eine AI-natürliche Engineering-Reliability-Plattform, die Entwicklern und AI-Agenten direkte Einblicke in das Verhalten von Software während ihrer Ausführung bietet. Ihre Technologie kann dynamisch Protokolle, Snapshots, Metriken, Spuren, Variable-Werte und Ausführungskontext von Live-Anwendungen erfassen, ohne dass Code-Änderungen oder Neu-Deployments erforderlich sind. Das Unternehmen erweitert diese Laufzeitintelligenz zunehmend auf AI-gestützte Software-Entwicklung durch Lightrun MCP, das das Model-Context-Protokoll verwendet, um Coding-Assistenten und agenbasierten Tools Live-Anwendungskontext anstelle von statischem Quellcode bereitzustellen. Dies ermöglicht es AI-Systemen, Produktionsprobleme zu untersuchen, Hypothesen gegen tatsächliches Ausführungsverhalten zu überprüfen und Root-Cause-Analysen durchzuführen, während sie gleichzeitig Unternehmenskontrollen wie rollenbasierten Zugriff und Redaktion sensibler Daten einhalten.

Ihre Karriere umfasst hands-on Software-Entwicklung und Architektur, Cloud-Kunden-Engineering bei Google, globale Lösungs-Engineering und jetzt Kunden-Lösungen bei Lightrun. Wie hat diese Kombination aus Software-Bau und direkter Arbeit mit Unternehmenskunden Ihr Verständnis davon geprägt, was einen beeindruckenden AI-Agenten-Demonstration von einem System unterscheidet, das in der Produktion vertrauenswürdig ist?

Es gibt einen großen Unterschied zwischen der Demonstration dessen, was ein AI-Agent kann, und der Erbringung des Beweises, dass er in einem Unternehmensumfeld vertrauenswürdig ist. Dies liegt daran, dass Agenten nur ein Teil eines produktionssicheren Systems sind. Der Rahmen um sie herum ist ebenso wichtig. Er muss least-privilege-Zugriff, Aktivitätsüberwachung, Erhaltung einer Audit-Spur, Verhinderung unannehmbarer Risiken und Einbeziehung eines Menschen bei Bedarf durchsetzen.

Agente Systeme sind von traditioneller Software inhärent verschieden, da Entwickler nicht genau vorschreiben, wie das System funktionieren wird. Wir setzen ein Ziel, stellen Werkzeuge und Anleitung bereit, und das Modell bestimmt, wie es vorgehen wird. Diese Flexibilität ist leistungsfähig, aber sie macht auch das Verhalten des Systems schwerer vorherzusagen.

Für Unternehmen, insbesondere solche in regulierten Branchen, sind Produktions-Workflows, die normalerweise funktionieren oder unvorhersehbar viel Zeit benötigen, um abzuschließen, nicht akzeptabel. Produktionsumgebungen enthalten sensible Daten, Quellcode und geistiges Eigentum, sodass Organisationen in der Lage sein müssen, zu verhindern, dass Agenten diese Informationen preisgeben oder unannehmbare Wege einschlagen, um ihre Ziele zu erreichen. Dies wird immer wichtiger, da jede Woche ein neues Beispiel für ein AI-System bringt, das, in seinem Streben nach einem Ziel, verwundbar wird oder eine Sicherheitslücke verursacht.

Die meisten Führungskräfte, mit denen ich spreche, bewerten Agenten noch immer so, wie sie einen neuen Mitarbeiter bewerten würden: anhand ihrer Fähigkeiten, ihres Urteilsvermögens und ihrer Ausgabe. Die eigentliche Frage ist nicht, ob der Agent intelligent genug ist. Es ist, ob das System um ihn herum in der Lage ist, die Momente zu erkennen und zu begrenzen, in denen er es nicht ist.

Viele Unternehmen glaubten anfangs, dass der Bau eines AI-Agents hauptsächlich eine Frage der Erstellung einer effektiven Aufforderung sei. Was haben Organisationen falsch verstanden, was die Ingenieur-, Architektur- und Betriebsanforderungen hinter produktionssicheren Agenten betrifft?

Ich denke, das größte Missverständnis war ein nahezu naiver Glaube an die Macht der KI, jedes Problem zu lösen, sobald sie eine gut geschriebene Aufforderung, relevanten Kontext und geeignete Werkzeuge erhält. Teams verbanden ihre LLM mit Code, Dokumentation, Tickets und historischer Telemetrie und erwarteten dann, dass sie aufgrund ihrer Fähigkeiten zu einer genauen Entscheidung gelangen.

Was sie nicht aufbauten, war ein Verifizierungsmodell für jeden Schritt der KI-Argumentation. Eine der großen Stärken der KI ist, dass sie probabilistische Argumentation verwendet, eine von vielen möglichen Routen findet und einschlägt, um ein Ziel zu erreichen. In komplexen, vernetzten Produktionsumgebungen führt diese Stärke jedoch zu ernsthaften Risiken: Eine einzelne Entscheidung kann zu Downstream-Regressionsstörungen, stummen Fehlern oder anderen unerwarteten Verhaltensweisen führen, die die Betriebsfestigkeit eines laufenden Systems gefährden.

Dies ist der Punkt, an dem deterministische Steuerung unerlässlich wird. Die Argumentation des Agents kann probabilistisch bleiben, aber die Checkpoints um seine Aktionen herum dürfen es nicht. Für einen Agenten, der an einem Engineering-Workflow teilnimmt, erfordert dies einen Verifizierungsschritt, der seine hypothetisierte nächste Aktion gegen die Produktionsrealität überprüft, ein deterministisches Tor und nicht einen weiteren probabilistischen Vermutungsschritt. Er muss sehen, welche Konsequenz diese Entscheidung haben wird, und sie nur dann genehmigen, wenn er festgestellt hat, dass die Aktion sicher ist.

Bei der Betrachtung der ersten Welle von intern entwickelten Unternehmensagenten, welche sind die häufigsten architektonischen Fehler, die Sie sehen, und welche Probleme können inkrementell korrigiert werden, anstatt eine vollständige Neukonstruktion zu erfordern?

Die Kernsorge, auf die ich immer wieder zurückkomme, ist die Validierung. Agenten können zu einer Black-Box werden: Sie sammeln Informationen aus verschiedenen Quellen und treffen Entscheidungen, die im Prinzip vernünftig aussehen, aber möglicherweise nicht für die Realität einer komplexen Produktionsumgebung geeignet sind.

Das deutet auf eine grundlegendere Veränderung hin, und es ist etwas, worüber wir bei Lightrun ständig sprechen, wenn wir Kunden helfen, agente Automationen für ihre Engineering-Organisationen aufzubauen. Teams müssen den agenbasierten Fluss selbst neu aufbauen und Tore für die Aktionen des Agents einrichten, um sicherzustellen, dass die Verwendung von Werkzeugen durch Aufsicht, Audit und Überprüfung überwacht wird. Durch die Bereitstellung eines starken Feedback-Schleifens für den Agenten – einschließlich Live-Laufzeit-Beobachtbarkeit – konzentriert sich sein Kontext auf das, was wirklich gerade passiert. Dieser Zugriff ist es, der es dem Agenten ermöglicht, seine eigenen Design-Entscheidungen, Root-Cause-Analysen und Fehler-Mitigations-Empfehlungen gegen die Produktionsrealität und nicht gegen Annahmen auf der Grundlage statischer Code- oder alter Telemetrie-Analyse zu überprüfen.

Eine dramatische Neukonstruktion ist nicht die einzige Option. Was inkrementell durchgeführt werden kann – und das ist nicht bahnbrechend, aber es ist wesentlich – ist die Investition in die Fähigkeiten, die das Verhalten des Agents bestimmen. Sorgfältig erstellte und ausgewertete Fähigkeiten drängen den Agent in Richtung eines deterministischen Workflows. Teams müssen die Systemarchitektur nicht vollständig neu entwerfen, um diesen Vorteil zu erzielen. Sie müssen lediglich die Gestaltung von Fähigkeiten mit der gleichen Strenge angehen, die sie jeder anderen Produktionlogik geben würden.

Warum funktionieren einige Agenten während kontrollierter Tests gut, aber beginnen, inkonsistente, unvollständige oder irreführende Ergebnisse zu liefern, wenn sie realen Benutzern, wechselnden Daten, externen Tools und komplexen Produktionsumgebungen ausgesetzt sind?

Kontrollierte Tests entfernen die meisten Variablen, die die Produktionsrealität definieren werden, mit der die KI konfrontiert wird. Die Daten sind kuratiert, das Toolverhalten ist vorhersehbar, die Berechtigungen sind bekannt, und wir decken einen Pfad ab, den wir vorhergesehen haben. Wenn Sie einen Agenten freigeben, um mit realen Benutzern und ihren Auswirkungen in Live-Systemen zu interagieren, vergleichen Sie nicht gleichartige Dinge.

Benutzer stellen mehrdeutige Anfragen und führen gleichzeitige Aktionen aus, der Systemzustand ist in ständigem Fluss, der Agent muss oft mit unvollständigen Daten arbeiten, und externe Tools bringen ihre eigene Latenz und Fehlermodi hinzu. Da das Modell probabilistisch ist, schafft jede neue Variable einen weiteren Ort, an dem der Workflow divergieren oder einen früheren Fehler verstärken kann.

Der gefährliche Teil ist, dass der Agent weiterhin so aussehen kann, als würde er korrekt arbeiten, während er inkorrekte, aber plausible Antworten produziert, die auf unvollständigen Daten oder Annahmen basieren, die in veralteten Informationen verwurzelt sind. Deshalb benötigen Produktionsagenten kontinuierliche Bewertung, die nach dem Start weiterläuft, explizite Behandlung fehlender Daten und Tool-Fehler sowie Live-Verifizierung einer Entscheidung, bevor sie eine hochwertige Aktion abschließt.

Lightrun legt großen Wert darauf, AI-Systemen Zugriff auf Laufzeit-Kontext zu gewähren. Welche Informationen bietet Laufzeit-Kontext, die herkömmliche Protokolle, Metriken und Spuren möglicherweise verpassen, und warum sind diese Informationen besonders wichtig für die Diagnose von Agenten-Fehlern?

Herkömmliche Beobachtbarkeit zeigt die äußeren Symptome des Systemverhaltens, oft aggregiert, beprobt oder durch Dashboards und Warnungen gefiltert, die auf Schwellenwerten ausgelöst werden. Sie sind in der Regel von Entscheidungen abhängig, die von Entwicklern zum Zeitpunkt der Code-Erstellung getroffen wurden: Welche Informationen werden in Zukunft von Interesse sein? Was ist es wert, protokolliert oder gemessen zu werden? Laufzeit-Kontext entkoppelt die Sichtbarkeit von dieser Notwendigkeit, im Voraus zu wissen, was möglicherweise von Interesse sein könnte, und bietet granulare Daten, die zeigen, was unter der Haube passiert und wie wir dorthin gekommen sind.

Die eigentliche Lücke ist die zwischen statischen und dynamischen Daten. Herkömmliche Protokolle, Metriken und Spuren sind statisch und liefern eine historische Darstellung dessen, was passiert ist. Lightruns Laufzeit-Kontext ist dynamisch. Er gibt einem Agenten die Fähigkeit, neue Instrumentierung in laufenden Code einzufügen und die genauen Variablenwerte, Funktionsargumente, Objektzustände, Aufrufstacks oder Verzweigungsbedingungen zu beobachten, wie sie auftreten.

Dieser Unterschied ist besonders wichtig für die Diagnose von Fehlern in agentengeneriertem Code, da diese häufig stumm sind. Ein Agent kann das falsche Tool auswählen, das falsche Argument übergeben oder auf der Grundlage einer veralteten Annahme handeln und dennoch seine Aufgabe abschließen, ohne dass ein Fehler ausgelöst wird. Ein solcher Fehler wird nicht in statischer Telemetrie angezeigt, da niemand im Voraus wusste, dass er instrumentiert werden musste. Unerwartetes Verhalten erfordert eine dynamische Untersuchung direkt auf dem laufenden System, wobei neue Instrumentierung genau an der Stelle eingesetzt wird, an der das Modell der Welt des Agents von der Realität abwich, anstatt sich auf das zu verlassen, was bereits aufgezeichnet wurde.

Das ist, was den dynamischen Laufzeit-Kontext zur natürlichen Verifizierungsebene für AI-generierte Entscheidungen im Engineering macht.

Wie können das Model-Context-Protokoll (MCP) und ähnliche Integrations-Schichten es Coding-Agenten ermöglichen, von echtem Ausführungsverhalten zu lernen, ohne ihnen exzessiven oder unsicheren Zugriff auf Produktions-Systeme zu gewähren?

MCP und andere kontrollierter Zugriff auf externe Tools (z. B. CLI-Wrapper) lassen einen Agenten eine spezifische, begrenzte Fähigkeit aufrufen, anstatt ihm breiten Zugriff auf ein System zu gewähren und ihm zu vertrauen, dass er sich wohl verhält. Ein Agent, der über einen MCP-Server für Laufzeit-Kontext verbunden ist, kann schreibgeschütztes Beweismaterial, den Wert einer Variablen, einen Aufrufpfad, ob ein Schwellenwert überschritten wurde, anfordern, ohne Schreibzugriff zu benötigen, ohne die Fähigkeit, etwas neu zu deployen, und ohne stehende Anmeldeinformationen für die zugrunde liegende Umgebung zu benötigen.

Wenn Sie einen ersten Agenten der ersten Generation neu entwerfen, wie sollten Unternehmen Tool-Berechtigungen, Speicher, Datenabruf, Bewertung, menschliche Aufsicht und Ausfall-Verfahren als Teile einer kohärenten Architektur und nicht als separate Funktionen angehen?

Sie können diese Teile nicht unabhängig voneinander aufbauen, da jeder von ihnen die anderen ändert. Die besten Orte, um zu beginnen, sind der Rahmen, die Hülle, die die Agenten-Schleife steuert, und die Gesamtdurchführung der Arbeitsabläufe, die mehrere Agenten und andere Akteure zusammenbindet. Für einen Root-Cause-Analyse-Workflow sollten Teams beispielsweise entscheiden, welche Beweise erforderlich sind, welche Systeme der Agent untersuchen darf, ob er eine Schlussfolgerung veröffentlichen oder nur entwerfen kann, wann ein Mensch die nächste Schritt genehmigen muss und was passiert, wenn Laufzeit-Beweise nicht verfügbar sind.

Sobald dieser Vertrag klar ist, bieten die Hülle und der Rahmen die Mechanismen, um diese Richtlinien durchzusetzen. MCP-Gateways können genutzt werden, um den Zugriff des Agents auf bestimmte Fähigkeiten zu beschränken, die für seinen Zweck relevant sind. Tools können mit least-privilege-Berechtigungen bereitgestellt werden. Der Speicher kann überwacht werden, wobei sensible Daten deterministisch redigiert werden. Der Abruf kann um die Beweise herum entworfen werden, die der Arbeitsablauf benötigt.

Bewertung, Aufsicht und Ausfall schließen dann den Kreis. Das System sollte messen, ob die Schlussfolgerungen korrekt und unterstützt sind, einen Menschen einbeziehen, wenn das Risiko oder die Unsicherheit einen definierten Schwellenwert überschreitet, und stoppen oder auf eine schreibgeschützte Empfehlung zurückfallen, wenn es nicht genug Beweise sammeln kann. Ein gemeinsamer Prüfbericht sollte den Auslöser, die Berechtigungen, die Beweise, die Tool-Aufrufe, die Genehmigungen, die Aktion und das Ergebnis verbinden. Das ist, was diese Komponenten zu einer Produktionsarchitektur und nicht zu sechs separaten Funktionen macht.

Welche Sicherheitsvorkehrungen sollten Agenten umgeben, die Live-Anwendungen untersuchen oder an Site-Reliability-Engineering-Workflows teilnehmen können, insbesondere in regulierten Umgebungen, in denen Zugriffs-, Datenschutz-, Prüfbarkeit- und Betriebsstabilitätskontrollen kritisch sind?

Dies war eine der zentralen Design-Fragen, als wir Lightrun AI SRE aufbauten. Ein AI SRE arbeitet nahe an einigen der sensibelsten Systeme in einer Organisation, also haben wir es als privilegierten betrieblichen Akteur und nicht als Chat-Assistenten entworfen. Eine wichtige Entscheidung war, die Inspektionsebene von der Aktionsebene zu trennen. Der AI SRE sammelt Beweise durch schreibgeschützte Integrationen und Lightruns sandboxbasierte Laufzeit-Instrumentierung, wobei der Zugriff durch Identität, Mandant, Dienst und Umgebung eingeschränkt ist. Er kann Live-Ausführung untersuchen und fehlende Beweise generieren, aber die Laufzeit-Inspektionsebene kann den Anwendungsstatus nicht ändern.

In einer regulierten Umgebung muss diese Grenze durch RBAC, SSO, Mandantenisolation, PII-Redaktion, Aufbewahrungssteuerung und einen Prüfbericht unterstützt werden, der zeigt, welche Tools und Beweise jede Schlussfolgerung unterstützt haben. Wir benötigen auch betriebliche Grenzen für die Menge an Daten, die gesammelt werden können, wie häufig die Laufzeit abgefragt werden kann und welche Aktionen eine Genehmigung erfordern. Wenn Beweise fehlen oder eine Schlussfolgerung nicht verifiziert werden kann, sollte der AI SRE dies sagen und die Entscheidung einem Menschen überlassen, anstatt so zu tun, als wüsste er mehr, als er tatsächlich weiß. Das Ziel ist kontrollierte Autonomie: nützlich genug, um eine Untersuchung zu beschleunigen, aber ausreichend eingeschränkt, um für das Live-System sicher zu bleiben.

Wenn Unternehmen über experimentelle Agenten hinausgehen, welche Messungen sollten bestimmen, ob ein Agent tatsächlich produktionssicher ist, und wie erwarten Sie, dass die Beziehung zwischen AI-Agenten und menschlichen Ingenieuren in den nächsten Jahren entwickelt wird?

Ich würde die Produktionssicherheit anhand der Häufigkeit beurteilen, mit der die Aktionen eines AI-Agents die gewünschten Ergebnisse produzieren, seine Schlussfolgerungen der tatsächlichen Produktion standhalten, unglaubwürdige Schlussfolgerungen vor einer Aktion abgefangen werden und ob er sichtbar und sicher fehlschlägt, wenn die Beweise nicht vorhanden sind. Für Engineering-Agente sollten wir uns auf verifizierte Ergebnisgenauigkeit, Beweisabdeckung, Zeit zur Bestätigung der Root-Cause, erfolgreiche Ausfallrate und Post-Aktions-Ergebnisse konzentrieren.

In den nächsten Jahren erwarte ich, dass Agenten mehr der Beweissammlung und der ersten Untersuchung übernehmen, sowie der Überwachung von agenbasierten Workflows und des kontinuierlichen Lernens aus Erfahrung und Feedback, während Ingenieure Richtlinien festlegen, Mehrdeutigkeiten auflösen, hochriskante Aktionen genehmigen und sich selbstverbessernde agente Systeme steuern. Vertrauen wird sich Schritt für Schritt ausbauen. Agenten, die ihre Schlussfolgerungen auf Live-Beweise zurückführen und klar angeben, was sie nicht verifizieren konnten, werden größere Autonomie erlangen. Diejenigen, die dies nicht können, werden auf enge, niedrige Aufgaben beschränkt bleiben, unabhängig davon, wie fließend sie klingen.

Vielen Dank für das großartige Interview. Leser, die mehr erfahren möchten, sollten Lightrun besuchen.