Deep Dive 214 – LangChain mit Christian Bromann

Wie hat dir die Folge gefallen?
Gut 👍
Schlecht 👎
(Keine Anmeldung erforderlich)

Wie baut man einen Agenten, dem man wirklich Arbeit überlassen kann? In diesem Deep Dive sprechen Jan und Dennis mit Christian Bromann von LangChain darüber, was heute alles dazugehört, wenn man Agents baut, testet, deployt und im Betrieb überwacht.

Christian beschreibt LangChain als ein Toolset, das den gesamten Agent Development Lifecycle abdeckt: vom Bauen über das Testen bis zum Deployen und Monitoren. Angefangen hat alles beim Monitoring, also beim Aufzeichnen aller Schritte, die ein Agent macht. Diese sogenannten Traces sind bis heute die Grundlage für vieles andere. Das Herzstück dahinter ist LangGraph, die Runtime, in der Agents laufen: Man baut einzelne Nodes, legt fest, wie sie durchlaufen werden, und jeder Schritt wird gespeichert. Über Middlewares kann man an jeder Stelle des Ablaufs eingreifen, etwa bevor ein Modell aufgerufen wird oder nachdem ein Tool ein Ergebnis liefert.

Ganz oben steht der Deep Agent, der Sandbox, Sub-Agents und nachladbare Skills mitbringt. Möglich ist das laut Christian erst, weil die Modelle inzwischen klug genug sind, zum Beispiel mehrere Tool-Calls parallel auszuführen.

Wir sprechen auch darüber, wer sich so einen Agenten überhaupt selbst baut, während es Agents doch längst von der Stange gibt. Für wiederkehrende Aufgaben im Unternehmen lohnt sich eine eigene, getunte Umgebung fast immer. Mit Fleet zeigt Christian ein Werkzeug, bei dem selbst nicht-technische Kolleg:innen per Prompt einen Agenten zusammenbauen, indem sie einfach ihre Tools wie E-Mail oder Jira verknüpfen: ein Agent, der Agents baut.

Zum Schluss wagen wir einen Blick in die Glaskugel. Christian sieht großes Potenzial in Open-Weight-Modellen. Statt jeden Monat große Summen an die großen Anbieter zu überweisen, könnten Firmen künftig kleinere, offene Modelle für ihren eigenen Use Case finetunen, auch aus Kostengründen und um die Kontrolle über ihre Daten zu behalten. Ob dieses Kostenargument wirklich trägt, diskutieren Jan und Dennis anschließend munter weiter.

Schreibt uns!
Schickt uns eure Themenwünsche und euer Feedback: podcast@programmier.bar

Folgt uns!
Bleibt auf dem Laufenden über zukünftige Folgen und virtuelle Meetups und beteiligt euch an Community-Diskussionen.

Bluesky
Instagram
LinkedIn
Meetup
YouTube

Musik: Hanimo

Transcript

SPEAKER_01 0:06

Hallo und herzlich willkommen zu einem neuen Deep Dive hier in der Programmierbar. Heute für euch am Start einmal der Jan Gregor Ingriebel und neben mir der Ausnahmsweise Dennis Becker. Was guckst du mich so an?

SPEAKER_00 0:19

Obwohl du sagst, ausnahmsweise.

SPEAKER_01 0:20

Ja, wir sind ja nicht so oft physisch im selben Studio. Das passiert ja nicht so häufig. Ich fühle mich hier immer noch sehr neu. Ihr habt alle so ein bisschen mehr Erfahrung schon hier damit. Ich war vorhin schon überfordert, die Lampen wieder anzukriegen, aber es hat alles funktioniert. Ton und Bild haben wir jetzt auch, Gott sei Dank. Und wir sind zwar zu zweit nur hier, aber zu dritt in diesem Gespräch, nämlich haben wir noch am Start Christian Brummann. Hallo Christian, schön, dass du da bist.

SPEAKER_03 0:42

Hallo Dennis, hallo Jan.

SPEAKER_01 0:44

Mir fällt gerade zum ersten Mal auf, dass das in dem Video komplett antiklimatisch ist, dieser Effekt, weißt du? In der Audioaufnahme. Da merkt man nicht, dass ein Gast dabei ist, bis man sagt so, und heute ist ein Gast dabei. Und dann sagt er das erste Mal Hallo. Und im Video sieht man jetzt die ganze Zeit schon Christian und wir reden. Da kommt darauf an, wie du zusammenschneidest.

SPEAKER_00 0:59

Du kannst ja in den ersten Frames nur uns zeigen.

SPEAKER_01 1:01

Ja, Challenge an Carlo, wir produzieren das jetzt einfach mal ein bisschen anders. Christian ist heute bei uns, um über Langchain zu sprechen und wie man Agents baut. Und Christian, ich habe mir vorhin nochmal dein LinkedIn-Profil angeguckt und da hast du ja schon ziemlich viel so gemacht. Also weiß nicht, was alles dabei schon auswendig noch Microsoft MVP und bei der OpenJS Foundation und WebDriver.io Maintainer habe ich gesehen. Und da muss ich ganz kurz ein besonderes Lob aussprechen, weil jeder, der früher mal, so wie ich, so ein Selenium-Cluster maintainen musste, da lacht Christian schon, mir treten traumatische Angstschweißperlen gleich wieder auf die Stirn. Weil das war früher alles so ein richtiger, darf man Pain in DS sagen oder müssen wir das rauspieten? Das ist okay. Und das ist.

SPEAKER_03 1:51

Ich fand, weil ich der Einzige gewesen bin, der das damals gerne gemacht habe, weil ich wirklich das Thema spannend fand, Browser-Automatisierung, fand ich immer, ich hatte einen Vorteil, weil alle haben mich da rangelassen und konnte mir dann die Bonuspunkte einheimsen.

SPEAKER_01 2:08

Ich bin äquivalent von so einer, wie heißt das, evolutionären Nische? So, du besetzt so eine Stelle, wo sonst niemand hin will und breitest dich dann da irgendwie aus. Ich muss sagen, es hat mir auch irgendwie immer Spaß gemacht, aber es war halt so ein sehr schwer zu debuggendes Ding. Weißt du, hast du so einen Selenium-Server und dann sind da ein paar Clients dran connected und irgendwas funktioniert nicht. Dann ist das das Network zwischen irgendwie dem Client und dem Server oder ist irgendwas in dem Browser oder hast du nicht gesehen? Das war schon immer.

SPEAKER_03 2:32

Jeder Tag ist ein neues Abenteuer, wenn es ums Debuggen geht.

SPEAKER_01 2:38

Das ist richtig. Aber ich wollte fast sagen, Gott sei Dank, aber sowieso wahrscheinlich kann ich sein. Wir reden ja heute nicht über Browser-Automatisierung, sondern wir reden über Langchain. Und ich glaube, Langchain ist in der Programmierbar das erste Mal so aufgetreten 2023 vielleicht? Spätest 2023, weißt du, hatten mal Christian Weiher zu Gast und haben wir über so AI-Integration und Rack und sowas alles gesprochen. Ich glaube, da war das ja das erste Mal inhaltlich so ein Thema. Und Langchain ist ja gefühlt so ein sehr junges Projekt und gleichzeitig in AI-Jahren gemessen schon so ein sehr altes Projekt. Weil das ja von Anfang an gefühlt so mit dabei war und ich habe das immer noch so im Kopf als das, wie gesagt, wir haben damals über Rack und Retrieval Augmentation gesprochen und so ein bisschen über Inference im Browser machen und so. Und das ist immer so, wo ich Langchain noch abgespeichert habe. Aber ich glaube, es ist mittlerweile viel, viel mehr. Und deshalb, Christian, bevor wir zu tief in das Thema einsteigen, wie würdest du denn Langchain gerade beschreiben?

SPEAKER_03 3:38

Ich würde Langchain beschreiben als eine Organisation, die Services und Tools baut, die den kompletten, wir sagen dazu, den Agent Development Lifecycle abdeckt. Also alles von das Bauen von Agents zum Testen der Agents, zum Deployen der Agents und zum Monitoren der Agents. Und das Interessante dabei ist, dass ich glaube, unser Steckenpferd sozusagen ist die Tatsache, dass wir auf quasi unser erstes Service war Monitoring. Das heißt, wir nehmen alle Traces auf, die so ein Agent macht, alle LLM-Calls, alle Two-Calls und wir speichern diese Daten und wir können da mit den Daten können wir now, da können wir jetzt quasi genau wissen, wo es bei dem Agent hängt, was der an welchen Stellen falsch macht, wo der falsche Abwägungen aufsetzt oder macht. Und wir haben jetzt quasi unsere eigenen Agents, die sich diese Traces angucken und dann sagen, hey, du könntest das verbessern, du könntest das verbessern. Das ist quasi so ein, so mehr, umso mehr Leute den Agent benutzen und umso mehr Monitoring-Daten wir bekommen, um mehr Traces wir haben, desto bessere Vorschläge können wir machen, wie man den Agent noch intelligenter machen kann.

SPEAKER_01 4:57

Okay, vielleicht machen wir noch zwei halbe Schritte zurück und sprechen noch einmal darüber, was so ein Agent eigentlich ist und was ein Agent für euch eigentlich ist.

SPEAKER_03 5:07

Ja, ich finde das mal ganz, ich glaube, das lässt sich ganz gut beschreiben, indem man aber die ganze Palette von Tools, die wir so mal in den letzten drei, vier Jahren gebaut haben. Ich meine, ich bin ja jetzt seit einem Jahr erst dabei, aber die es so gibt. Also als erstes, als Sunchain 2023 quasi gestartet ist, das erste, was die gebaut haben, sind quasi so einfache SDKs, um mit LLM zu kommunizieren. Damals waren Models noch nicht so, ähm die waren noch nicht so schlau, du konntest einen Prompt hinschicken und du hast quasi einen Prompt, einen Text zurückgekriegt. Und die haben halt Chains gebaut, die man miteinander verknüpfen konnte, um halt die Antwort eines Models in den Prompt eines anderen Models reinzuschicken. Und das hat funktioniert, aber Leute haben halt immer mehr gebaut und was halt her musste, ist irgendwas, was man deployen konnte und wo man halt die Informationen, auch wenn, ja, die Informationen zwischenzeitlich abfangen kann und quasi speichern kann. Und dahingeh wurde was gebaut, was wir Langgraph nennen. Langgraph ist quasi eine Library, mit der man sich Nodes aufbauen kann und sagen kann, welche Nodes wie ausgeführt werden. Also ich gehe von Node A zu B zu C und basierend auf welcher Kondition gehe ich D oder E. Und das konnte man dann deployen und jeder Step in dieser Node wurde quasi gespeichert, gecheckpointet und man konnte dann halt genau wissen, was passiert, welche Schritte passiert sind zwischenzeitlich. Das war quasi die Foundation für die ganze Observability. Und basierend darauf dann haben dann Leute mehr komplexere Systeme gebaut. Gerade in den Zeiten, wo Rack ein großes Thema war, konnte man in gewissen Nodes dann einbauen, dass man eine Datenbank Informationen holt und das Resultat hat man dann den nächsten Node gegeben, wo man dann den LLM-Call gemacht hat. Und Langerf ist unsere Agent Runtime bis heute noch, die führt alles aus, worum es geht, wenn es darum geht, einen Human in a Loop Workflow durch zu bauen oder ja halt so ein Agent zu deployen und laufen zu lassen.

SPEAKER_01 7:34

Wenn ich dich da vielleicht kurz unterbrechen darf, weil du hast ja eben schon beschrieben, wie ihr so in Langkraft diese Flows gebaut habt, ne? So ein Block nach dem anderen, Ergebnisse bauen, aufeinander auf und dann hast du gesagt, naja, das ist auch heute im Prinzip noch die Runtime, in der die Agents laufen. Genau. Ich stelle mir so ein Agent immer so sehr laihenhaft eigentlich eher als so ein Loop vor. Und wenn ich mir den in so einem Graph vorstelle, sieht das eigentlich für mich erstmal relativ unspektakulär aus, weil er sich halt mit so ein paar Schritten nur im Kreis tritt. Und diese ganzen Abzweigungen und wenn Ergebnis so, dann so oder hier Ergebnis weiterreichen und so. Das wird ja gar nicht mehr so stark gebraucht, oder? Also macht euch ein Agent nicht quasi die Runtime dann einfacher, als diese komplexen Graphen, die da vorher von Hand zusammengeschraubt worden sind?

SPEAKER_03 8:21

Genau, das wäre, dass dann die nächste Abstraktion, die wir darauf gebaut haben, als dann letztes Jahr, quasi das Jahr der Agents, der React-Agent oder der React Flow quasi sehr populär wurde, haben wir quasi diesen React Flow auf ein Langgraph aufgesetzt. Und das wirklich einfach mit einer einfachen Create-Agent-Fang-Funktion abgedeckt, wo man dann einfach, hier sind ein paar Tools, hier ist eine System Prompt und wir haben halt halt im Hintergrund den Graph aufgebaut. Kommt noch, dass wir als Alleinstellungsmerkmal noch Middlewares eingebaut haben. Das bedeutet, dass du quasi Hooks hattest bevor du ein Model benutzt hast oder nachdem du ein Model oder LLM-Resultat zurückbekommen hast, bevor du ein Tool ausführst oder nachdem du ein Tool-Result bekommen hast. Du konntest halt in jeder Stelle dieses Tool-Loops eingreifen und Ergebnisse verändern oder was hinzufügen, was fixen. Das war schon ziemlich hilfreich, weil wir damit viele Middlewares bauen konnten, die gewisse Workflows abgedeckt haben und Sachen vereinfacht haben, die anderweits ein bisschen schwieriger gewesen sind. Und auf dieser Foundation nun haben wir einen Deep Agent gebaut, der quasi der Create Agent oder der React Loop ist, aber mit quasi der nächsten Generation von Komponenten, die ein Agent heutzutage braucht, was zum Beispiel die Sandbox ist, was zum Beispiel Subagents sind oder Skills, wie Skills geladen werden, progressives Laden von spezifizierten Fähigkeiten. Das findet sich nun alles in diesem Deep Agent-Paket drin. Und gerade letzte Woche habe ich angefangen, quasi eine Stufe weiter höher zu bauen. Wenn es darum geht, wenn man ein Agent in deiner Organisation jetzt benutzen will, triggerst du die ja nicht in einem Terminal, sondern du willst einfach über Slack ein Agent die Message schicken. Und da geht es dann darum, okay, wie nimmt so ein Agent eine Identity an? Das heißt, führt der Agent einen Auftrag für dich aus, für eine Organisation, für ein Team. Basierend darauf hat der Agent auch nur spezielle Zugriffe auf Repositories oder auf Tools. Und das ist quasi diese nächste Generation von Agents oder Frameworks, die wir sehen. Vressel hat vor zwei Wochen Eve rausgebracht. Das Flu-Framework ist von Fred Shot. Gibt es mittlerweile schon ein bisschen länger? Das sind so diese nächste Generation von Agenten, Frameworks, die sich jetzt so entwickeln. Und ja, Langstein in den letzten drei Jahren ist quasi interessanterweise konnte man sehen, wie so die ganzen Primitive sich jetzt aufgebaut haben. Obwohl Langstein in selber schon, so dieser React-Loop, der, man hat darüber schon geredet, 2023. Damals waren halt die Models noch nicht klug genug. Und diese Abstraktion, die wir alle bauen, jetzt, die können wir auch nur tun, weil die Models klüger sind, die können jetzt Toolcalls gleichzeitig laufen, also gleichzeitig ausführen. Das konnte man früher nicht und deswegen hat sich das früher auch noch nicht gelohnt, diese Abstraktion zu bauen. Das kommt jetzt alles, als die, so als die Models jetzt immer klüger wären.

SPEAKER_01 11:53

Du hast gesagt, es gibt immer mehr diese Agent-Frameworks von ganz vielen verschiedenen Anbietern, die es jetzt im Prinzip jedem erlauben, so seinen eigenen Agent zu bauen und bei euch kommt noch entscheidend hinzu, dass ich mein Agent dann auch einfach bei euch laufen lassen kann. Das ist ja auch nicht so selbstverständlich. Bei manchen gibt es nur das SDK dazu, bei manchen vielleicht noch ein bisschen Inference oder so, aber manchmal muss ich auch meinen Agenten dann selber betreiben. Lasst uns vielleicht einmal kurz darüber sprechen, was es alles braucht, um das betreiben zu können. Also was muss ich entweder selber mitbringen oder was stellt ihr quasi im Prinzip schon im Hintergrund so bereit, um das für mich nutzen zu können? Ich sag mal, der allerbanalste Teil davon ist, ich brauche Compute, weil irgendjemand muss das Ganze ausführen. Ich brauche Inference, irgendjemand muss mir ein Model bereitstellen oder ich brauche ein lokales Modell, was ich irgendwie nutzen kann. Aber was brauche ich noch?

SPEAKER_03 12:45

Ein Agent ist oder ein Agent-Server ist im Prinzip nichts anderes als ein Backend, welches dir gewisse Endpunkte zur Verfügung stellt, um so ein Agent zu triggern. Im einfachsten Fall. Wir haben quasi einen Endpunkt, wo du dem Agent einen Probe checken kannst und dann kriegst du halt einen Response zurückgestreamt. Und den kannst du dann halt auf einer App zeigen und mit React Hooks quasi streamen, wie man das so schön kennt. Dazu bräuchte wahrscheinlich jeder noch so einen. Wir nennen das einen Checkpointer, das bedeutet eine Stelle, das es erlaubt, dir den Schritt, das der Agent macht, abzuspeichern und die Möglichkeit hat, quasi ein Thread, den du mit einem Agent gestartet hast, auch wieder von der Datenbank zu laden und quasi an einer gewissen Stelle wieder weiterzumachen. Aber im Prinzip, das ist im High-Level schon das, was es braucht. Ich habe jetzt noch nicht gesehen, dass jemand einen lokalen Model mit seinem Server deployt irgendwo hin. Das wäre ein bisschen, ja, weiß nicht, wie das mit den Ressourcen funktioniert, aber meistens nimmt man dann ein Model oder hat sein API-Key auf dem Server dann geladen und kann dann das Model dann irgendwie remote benutzen.

SPEAKER_01 14:10

Du hast ja auch schon ein Tool-Calling angesprochen. Um das zu ermöglichen, bedarf es ja irgendeiner Umgebung. Also das wird ja nicht so sein, dass wenn mein Agent bei euch jetzt irgendwie ein Tool ausführt, dass er dann da Bash als Route irgendwie auf der Kiste, wo das alles läuft, macht, sondern da brauchst du irgendeine Sandbox, irgendein Environment, was da irgendwie vorgefertigt wird. Was und wie stellt ihr da bereit?

SPEAKER_03 14:35

Ja, da gibt es mehrere Möglichkeiten. Die meisten werden wahrscheinlich eine Sandbox benutzen und sich mit einem Sandbox-Provider verbinden, wo man dann relativ schnell eine Sandbox zur Verfügung gestellt bekommt, die man auch vorher Provisioning, also vorher aufbauen kann, wo du sagst, ich brauche immer dieses Repository in meiner Sandbox, dann kann man so eine Sandbox vorher zusammenbauen und die dann snapshotten und dann kann man immer wieder auf der gleichen Sandbox aufbauen. Wo wir ein bisschen mehr investiert haben, sind, wir nennen es Interpreter. Das bedeutet, dass wir quasi anstatt eine Sandbox zu benutzen, können wir einfach den Agent eine JavaScript-Umgebung geben, die es benutzen kann, um so einfache Code-Geschichten ausführen zu lassen. Das benutzen wir aber meistens, um den Orchestrator eine Möglichkeit zu geben, Sub-Agents über Code aus zu triggern. Man kann sich so vorstellen, wenn man jetzt einen Agent hat und man sagt, gibt den Agent so eine CSV-Datei mit 100 Reihen drin und man gibt das den Agent und sagt, guck dir jede Reihe an und man stellt eine Frage dazu, dann wäre das ein bisschen, dann könnte der Agent jetzt einen Toolcode nach einem anderen machen oder er könnte halt einen JavaScript-Code erstellen, weil Agents oder LLMs sind ziemlich gut im Coding, der quasi über diese CSV-Datei einmal rübergeht und die ganzen Zellen parallel, für parallel ein Sub-Agent aufruft. Also wir haben zusätzlich zum Sandbox noch so einen Enterpreter, so eine RAPL-Umgebung, die über Quick.js relativ sicher im Agent selber läuft, ohne dass man eine Sandbox braucht. Aber das, wie gesagt, mehr für Orchestration von Subagents und kleinen, also einfachen Coding-Problemen.

SPEAKER_01 16:40

Du hast auch schon das Thema Identity angesprochen. Wer ist mein Agent und was darf er? Wenn ich mir jetzt überlege, ich will hier bei uns, bei Lotum, so ein Agent mal bereitstellen für alle in Slack, wie du gerade angesprochen hast. Wie viele Gedanken muss ich mir da zum einen um das Thema Access und Authorization machen, aber auch um das Thema Identity des Agents selbst. Also wie wichtig ist es, dass ich dem im, sagt man da bei dem Agent auch System Prompt, ist das das System Prompt von dem Agent, dass ich ihm quasi vorher so ein bisschen beschreibe, wer er ist und was er können soll, wofür er zuständig ist, versus wie viel kommt da eigentlich aus dem Gespräch mit dem Agent und den Mitarbeitern selbst raus?

SPEAKER_03 17:25

Ja, also das eine ist dem Agent quasi ein Bewusstsein zu geben, was man so eine System-Prompt haut, wo du sagst, du bist ein hilfreicher Assistent für das Team ABC. Das ist quasi mehr so ein Bewusstsein, worum es in Identity mehr geht, ist, dass man herausfindet, wer den Agent gestartet hat und da basierend darauf gehend diesen Actor quasi eine gewisse Verfügung gibt über welche Tools er benutzen kann und welchen Zugang er auf gewissen Resourcen hat. Und das gibt es tatsächlich so noch nicht in vielen Frameworks. Das wird jetzt langsam, ich sehe das bei Flu, gibt es so einfache Andeutungen für diese Modelle, aber ich habe das so noch nicht gesehen, dass es sowas gibt, das auch relativ neu, dass man, dass man sieht, dass man solche Probleme jetzt bei Agenten auflösen muss, gerade wenn, gerade als viele das jetzt in großen Organisationen deployen und mehrere Teams auf Agenten zugreifen. Viele bauen das gerade noch selber quasi ein. Und wir versuchen das halt ein bisschen zu abstrahieren und das einfach zu machen, dass du sagen kannst, okay, wenn dieser User von Slack auf meine Agenten zutrifft, dann kann ich dem gewisse Zugriffe auf dieses Repository geben und dann kann ich auch den Commits, den ich erzeuge mit meinem Agenten, so erstellen, dass es quasi ein PA wird, wo auch sein Name dann draufsteht. Und das macht man mittlerweile alles noch händisch und da versuchen wir halt auch Abfraktionen zu bauen, dass es alles ein bisschen einfacher wird.

SPEAKER_00 19:10

Und ist ja auch das Ansatz, wenn das praktisch in einem Team, in einer Team-Konstellation ist, weil du das gerade über Slack sprachst. Aber es ist schon die Idee, ich als Dennis gebe eine Aufgabe und er erledigt das praktisch für mich und committ dann auch in meinem Namen.

SPEAKER_01 19:28

Genau. Und wessen Problem in Anführungszeichen muss es denn überhaupt sein? Weil eigentlich muss es den Agent ja gar nicht so interessieren, oder? Also der Agent weiß, mit wem oder für wen er das quasi macht und dann ist ja dieses Identity-Thema eigentlich eher so eine Herausforderung für die Tools, die es, die er eventuell aufrufen muss und gar nicht mal so für den Agent, also für das LLM und den laufenden Prozess quasi so selbst, oder?

SPEAKER_03 19:57

Das kann man, also das ist dann immer bei jedem, jedem überlassen, wie er sein Agent definieren kann. Klar kannst du diesen Agent auch sagen, einfach committe mit deinem Namen, mit dem Agent seinen Namen oder seinen Autidentifikation. Ich glaube, wo es dann kritisch wird, ist, bei bestimmten Leuten bestimmten Zugängen zu geben, was es dann halt, was dann halt über Identity auch gemappt wird.

SPEAKER_01 20:25

Genau, aber das ist ja für den laufenden Agenten quasi intransparent, sondern ich muss diese Identität, ich muss wissen, das ist Dennis und dann muss ich es dann alle meine Tools, meine MCP-Server, meine, keine Ahnung, was weiterreichen, dass mein Git-Command auf der CLI muss Dennis seine Identität haben. Wenn ich auf Confluence zugreife über MCP, muss ich das mit Dennis seiner Identität machen. Aber den Agent selbst stört es ja quasi nicht, ob das jetzt Dennis ist oder Jan oder Christian oder Hans Müller, sondern für ihn ist das so ein Transiant-Ding, was er im Prinzip immer nur mitreicht während diesem ganzen Gespräch.

SPEAKER_03 21:00

So sieht es aus, genau.

SPEAKER_00 21:03

Ich muss trotzdem nochmal ein bisschen grundsätzlicher fragen, wo so ein bisschen der Einstiegspunkt ist oder beziehungsweise wo ihr da genau hängt in diesem Ding. Also ihr bietet ja keine LLMs an, das heißt im Hintergrund connectet man dann ein Model seiner Wahl. Genau. Und übernehmt ihr trotzdem praktisch die Harness, also das, was noch außenrum passiert, um mit dem Modell zu sprechen, oder basiert das dann auch auf der Harness von irgendeiner Umgebung, mit der ich sowieso interagiere?

SPEAKER_03 21:46

Also du kannst generell jeder Harness nehmen oder jedes Agent-Tool, was es gibt, und dir einfach nur die Services picken, die du möchtest. Wenn du ein Agent bauen willst mit Langchain-Tools, dann kannst du das mit Langchain-Tools machen, aber die Trac irgendwo anders hinschicken. Wenn du Pi oder Cloud Code benutzt, aber willst die Agent Traces bei uns erhalten, dann kannst du die Agent Traces zu uns schicken. Ich weiß nicht, wie viel, ob man nur, ich glaube, man kann nur Agent Harnesses, äh, Longchain-Harnesses auf uns deployen. Könnte sein, dass ich da falsch liege, aber Deployment ist ein eigenes Thema. Also es gibt einmal die Harnesses, die du bauen kannst, entweder mit Longchain-Tools oder nicht mit Longchain-Tools. Observability, die du machen kannst, entweder auf unserer Plattform oder auf anderen Plattformen. Evales, die du runter laufen lassen kannst, also Agent Testing, entweder auf unserer Plattform oder auf anderen Plattformen. Da gibt es unsere Kunden, die mixen vieles zusammen und es gibt Kunden, die nur Longchain benutzen, aber ich glaube, die Mehrheit hat so, die nutzen nur Observability, die nutzen nur unsere SDKs, um Agents zu bauen. Wir locken jetzt die User nicht ein und sagen, hey, ihr müsst nur unsere Sachen benutzen, wenn ihr irgendwas von Langchain benutzen wollt.

SPEAKER_00 23:11

Okay. Und hast du konkrete Use Cases oder Companyarten vielleicht oder Branchen oder auch individuelle, wo du sagen würdest, da sollte man mal reingucken, weil man dann einen Mehrwert hat?

SPEAKER_03 23:26

Ich glaube, jede Firma, die in irgendwelchem Sinne digital arbeitet, da werden sich Use Cases finden. Also in unserer Firma hat jedes Team mindestens ein oder zwei Agenten, und das ist nicht nur das Engineering-Team. Also wir haben ein Go-to-Market-Team, das ein Go-to-Market-Engine hat, das mit Salesforce verbunden ist und mit den ganzen Tools, die Go-to-Market benutzt, um herauszufinden, wie es bei den Kunden steht. Wir haben Finance Agents, die wissen, wie uns ums unsere Finanzen steht. Wir haben mehrere Coding-Agents, die bei uns laufen. Ich glaube, da gibt es der Kreativität keine Grenzen. Und was jeder Schritt, wo der quasi automatisiert werden kann, kann, oder jeder Arbeitsschritt, der quasi, wo man nicht so viel intelligent, wo man keine persönlichen Entscheidungen treffen muss, kann man mit Agenten abbilden.

SPEAKER_01 24:33

Stopp, bevor du die nächste Frage stellst, ich würde nämlich aufbauend auf der Frage stellen, für wen lohnt es sich denn dann, so einen eigenen Agenten zu bauen? Weil es gibt ja mittlerweile auch Agenten, ich sag mal, von der Stange. So, ich kann bei Entropic kann ich zu Cloud Cowork gehen und da im Team mitarbeiten. Ich kann bei OpenAI auch hier Codex in den Codexbot in Slack reinhängen. Also wer baut sich das denn selbst und was erhofft man sich davon? Oder für wen ist das halt besonders rentabel, da so eine Schicht tiefer zu gehen und zu sagen, naja, wir schrauben das hier lieber selbst zusammen?

SPEAKER_03 25:08

Ich glaube, es hängt davon an, wie welchen Use Case du hast und wie speziell er ist. Ich glaube, in den meisten Fällen kannst du dir eine Coding-Harnes nehmen, wie bei uns so ein Deep Agent, dem Deep Agent ein paar Tools geben oder mit dem MCP-Server verbinden und dann damit starten. Da gibt es nicht so viel, wo ich sagen könnte, da gibt es ein, zwei Stellen, wo du dann doch selber deine eigenen Harness bauen willst. Gerade weil wir, weil ich weiß, dass eine gute Harness zu bauen sehr anstrengend sein kann. Da gibt es so viele Knöpfe, die man drehen kann, um eine Harnis besser zu machen. Da ist es oft besser beraten, wenn man einfach so ein existierende Harness benutzt und die Komponenten einfach dazu gibt. Klar kann man immer noch dann dahin gehen und sagen, okay, ich will den Agent verbessern und E-Walts aufbauen und versuchen, die System-Prompts zu tunen, um bessere Resultate zu kriegen. Ich glaube, das sollte man eh immer machen. Es gibt nicht wirklich so ein Agent, klar kann man sich Codex runterladen und Codex benutzen für Coding, aber es gibt für so Workflows innerhalb einer Firma würde ich halt auch immer hinterhin gehen und sagen, eine Hannes aufbauen und dann versuchen, die zu tun, um immer bessere Resultate zu kriegen.

SPEAKER_00 26:34

Ich stelle es mir auch so ein bisschen wie so ein Katze-und-Maus-Spiel vor, oder? Ich meine, also es ist ja, ich würde behaupten, wahrscheinlich, oder meine aktuelle Vermutung ist, wenn man eure Tools nutzt, ist man ein bisschen mehr an der Cutting Edge und hat vielleicht noch mehr Möglichkeiten, verschiedene Dinge zu individualisieren und möglich zu machen, so die vielleicht so out of the box mit einem Klick nicht gehen, was vermutlich dann so in der Entwicklung halt ein paar Monate später vielleicht ein Teilaspekt ist von einem der großen Anbieter. Vielleicht nehmen wir mal Cloud Tag als Beispiel, weil wir es eben mit dem Slack waren, wo sie jetzt auch sowas gebaut haben, wo ein Teil davon eben abgenommen wird und auch gemacht wird. Und in meinem Kopf, also zumindest auch so der Wahrnehmung, war das ja auch immer schon so ein bisschen, ne, dieses, also dass man mit Langchain und den Tools drumherum halt die Möglichkeit hatte, irgendwie noch einen Schritt weiter zu gehen zu dem, was jetzt erstmal so das Modell von Haus aus irgendwo angeboten oder angeboten hat. Wie macht ihr das denn? Also ihr sagt schon selbst, dass ihr auch selbst die Agent dann nutzt, so in euren Alltag. Aber ich stelle mir es halt auch sehr spannend vor, an dieser Entwicklung irgendwo, praktisch an dieser Meta-Ebene vorne zu arbeiten, um mal zu gucken, was sind denn die nächsten Schritte, die man gehen kann und wo ist man so ein bisschen limitiert? Wann ermögliche ich ein neues Modell beispielsweise Dinge, die vorher nicht möglich waren? Warn es einfach nur eine schlaue Tooling-Idee, weil man sagt, hey, das wäre doch gut, das in Prozessen abzubilden. Also wie treibt ihr da so ein bisschen das Produkt voran? Und ich weiß nicht, ob es in dem Sinn oder eine späte Sprache noch, äh, Sprache, eine weitere Frage, Anschluss gleich ist, was so ein bisschen euer aktuelles Geschäftsmodell dahinter ist.

SPEAKER_03 28:24

Genau, also wir halt, also wir haben eben, wenn man irgendwie wieder zurückgeht, mit Langraf angefangen. Viele unserer Kunden benutzen halt immer noch Langraf, die bauen halt immer noch diese Notes auf und haben halt relativ sehr kosto, also spezifische Workflows, die sie abdecken wollen dadurch. Und wir sehen halt mehr und mehr Leute jetzt so ein Create Agent, die bauen halt so ein Create Agent oder gehen halt eine Stufe weiter höher, bauen halt ein Deep Agent und hoffe, dass halt viele Leute auch diese Managed Deep Agent benutzen, weil es halt einfach einfacher ist, gewisse, wenn man das schon drei, vier Mal gemacht hat innerhalb der Firma, dann merkt man, okay, das Pattern bleibt das gleiche, ist eigentlich nicht immer anders. Und es gibt nicht wirklich, ich würde sagen, es gibt nicht wirklich immer, jeder Workflow braucht nicht immer gleich ein Agent. Also es gibt viele Workflows, wo man mit Langra sogar besser aufgestellt ist, weil die Schritte, die man macht, die sind halt immer die gleichen. Man hat halt ein paar LLM-Calls in gewissen Nodes drin, die dann einem helfen, gewisse Workflows abzubilden. Aber ein Deep Agent kann auch ein bisschen Overkill sein für gewisse Sachen, wo die Aufgabe relativ einfach ist, wo man keine Sub-Agents braucht, wo man keine Sandbox braucht, wo man einfach nur gewisse Informationen zurückgeben will, basierend auf Daten, die sich in einer Datenbank befinden, zum Beispiel. Also dahingehend gibt es nicht wirklich so, man sollte immer Deep Agent benutzen oder immer auf eine Agent-Harness zurückgreifen, die es so im Markt gibt. Da bietet Langchain schon so eine Auswahl an, so an von wie viel Intelligenz willst du in so einer Harness packen oder wie viel Komplexität willst du da reinhauen?

SPEAKER_00 30:07

Lieg ich falsch mit der Aussage, wenn das Gefühl ist, dass es gerade irgendwie für Unternehmen und das Rollout von solchen Dingen irgendwie auch interessant ist, weil man gerade durch Observability, also weißt du auch, dieses Optimieren und sowas, ist das auch ein Use Case, den ich so als Single-Contributor, ich mache irgendwie mein eigenes Ding, wo ich von profitieren kann, oder sind das Features, die eher in einem Unternehmenskontext gut funktionieren?

SPEAKER_03 30:33

Observability im großen Rahmen, glaube ich, eher für einen Unternehmenskontext, wenn du jetzt deinen eigenen Agent baust, der dir beim Maintain eines Repository hilft, da guckst du wahrscheinlich eher selten in die Observabilities rein, weil du eher an den Agenten Resultaten interessiert bist. Ich glaube, Evales auf der anderen Seite sind halt immer gut, weil du halt immer versuchen willst, deinen Agent zu tun. Gerade wenn du deine Harness selber aufbaust, ist es halt immer gut daran gelegen, Evals zu bauen. Ich kann ein Beispiel nennen. Ich habe, das nennt sich, ich habe es schon wieder vergessen, aber das nennt sich Zeitzeuge. Zeitzeuge.dev habe ich einfach mal gebaut, um Performance-Probleme in meiner JavaScript-Applikation zu finden. Und den habe ich halt Evales gegeben, einfach ein Code-Repository, wo ich gewisse Probleme eingebaut habe. Und ich habe halt E-Walts drum gebaut, um herauszufinden, ob mein Agent dann all diese Probleme findet und die richtigen Vorschläge macht, die Probleme zu beseitigen. Und ich glaube, für jeden Use Case, wo man dann so ein Agent baut, ist, glaube ich, so Evales das Einzige, wo ich sagen würde, ja, das ist schon interessant für jeden Agent. Das muss man nicht bei uns laufen lassen, das kann man auch einfach lokal laufen als so eine Art Test. Ich glaube, wenn es darum geht, wenn man Production Load kriegt, das heißt, wo man dann deine Agenten von Leuten in deiner Firma benutzt werden und dann ist es schon interessant, so zu sehen, okay, ich kann mir aus diesen Traces, die durch die Observability erstellt werden, Datensets bauen, die ich dann über Jeweils laufen lasse, um halt ein besseres Bild über die Fähigkeit meines Agenten zu bekommen.

SPEAKER_01 32:21

Wäre es eine richtige Einordnung zu sagen, Observability ist eigentlich immer dann interessant, wenn ich davon ausgehe, dass mein Agent denselben Job halt wirklich mehrere Male macht. Also wenn ich jetzt, weißt nicht, ich habe hier unseren Slack-Agent, der unser Confluence durchwühlt oder sowas und ich werde wirklich gucken, okay, wird er besser oder schlechter da drin, so Ergebnisse zu finden. Oder ich habe einen Agent, der unsere BI Deshports baut oder ich will wissen, okay, wird er besser oder schlechter oder schafft er überhaupt die Aufgabe zu erfüllen in den meisten Fällen. Wohingegen, wenn es jetzt so dein privater Agent ist, dein Open Claud oder dein Pi oder sowas, dann zu sagen, naja gut, der macht ja immer sehr viele unterschiedliche Aufgaben, meistens nur einmal und da kann sich quasi gar nicht so ein Pattern ergeben, was du überhaupt mit Observability anschauen kann.

SPEAKER_03 33:11

Ja, und du gehst auch davon aus, dass wenn du ein Agent benutzt, wie ich benutze zum Beispiel Cursor als Coding Agent, ich gehe mal davon aus, dass die Leute bei Cursor ihre eigenen Evales laufen lassen und diesen Agenten selber testen. Da brauchst du, wenn du einen Agent von jemand anders benutzt, dann hoffst du, dass der durch E-Wites gut abgedeckt ist. Das machen wir mit Deepagen genauso. Wir haben mehrere Evales laufen und jedes Mal, wenn wir in der Harness was verändern, sei es eine System-Prompt oder wir nennen einfach nur ein Tool um, dann laufen wir die komplette Harne, die kompletten Eweil-Sets durch, um zu sehen, dass es da nicht irgendwelche Änderungen gibt. Ich glaube, wenn man halt so einen Agenten selber baut für seinen eigenen Use Case, dann sind Evales schon sehr hilfreich, weil man genau weiß, okay, ich baue den Agent, um Problem X zu lösen und kann dir dieses Problem X auch mit diesen Inputs zuverlässig lösen.

SPEAKER_04 34:09

Und würdest du.

SPEAKER_00 34:12

Oder funktioniert das dann auf diese eine Ebene höher oder Ebene nicht mehr, wenn man jetzt du meintest gerade, du nutzt Cursor, wenn ich jetzt irgendwo eine Programmieraufgabe habe und will unterschiedliche Coding-Agents miteinander vergleichen. Ist das auch was, wo du sagen würdest, das kann man damit machen oder ist das dann außerhalb des Scopes?

SPEAKER_03 34:38

Also es gibt ja die sogenannten Benchmarks. Terminalbench ist zum Beispiel ein sehr bekanntes, welches hier quasi eine Reihe von Problemen gibt und du kannst es in so eine Harness einpacken, die quasi alle Agenten laufen lassen kann. Das nennt sich Harbor. Ist mittlerweile ein relativ bekanntes Framework, um halt gewisse Problemsets auf diverse Agenten loszulassen und dann gibt es halt so eine Sache wie Terminal Bench, wo du sehen kannst, okay, für dieses Set auf Problemen, Coding related, schneiden diese Harnisse unterschiedlich ab. Das Ding mit solchen Terminal Benches oder mit Benchmarks und generell ist, dass wir oft so ist, dass die Teams dann versuchen, auf diese Probleme, die diese Bench hier gibt, quasi zu optimieren. Und das ist dann, dann hast du ja wieder deinen eigenen Bias drin für, weil die Probleme sind ja auch speziell in einer gewissen Art und Weise und kommen wahrscheinlich im Alltag eher weniger vor. Das heißt, wir sehen, dass es nicht immer das Beste ist, wenn man, also es muss nicht immer heißen, wenn irgendein im Terminal Bench gut aufgestellt ist, dass es auch generell eine gute Harness ist, das würde ich dann immer bezweifeln.

SPEAKER_00 35:56

Ja, da kam gerade ein bisschen Gedanken, weil wir hier auch immer mal wieder Diskussionen haben, jetzt irgendwie ein neues Modell rauskommt, dann nutzt jetzt einer irgendwie Fable 5 und andere Claude Opos oder GPT-5.5 oder 5.6 oder was auch immer. Und bis jetzt ist es halt immer so ein Gefühlsding, so ein bisschen auch, ne? Also dass man sagt, ja, okay, hat jetzt vielleicht besser funktioniert, wenn man den Thinking-Mode auf irgendwas stellt. Ob es dir sinnvoll erscheint, ob man dann praktisch so ein eigenes Benchmark oder eigene E-Balls macht für das Environment, was man selbst hat. Also, ne, die Projektstrukturen, die Aufgaben, die und so weiter.

SPEAKER_03 36:35

Ja, wie gesagt, da würde ich dahin gehen, wenn man eine Harne von jemandem anders benutzt, dann würde ich davon ausgehen, dass die Harne schon relativ gut getuned sein sollte. Nur wenn man seine eigene, seinen eigenen Agent baut, wo man seine eigenen Tools zur Verfügung stellt und seine eigenen System Prompt dazu schreibt, dann glaube ich, sind Ewars schon gut, um dann das Tuning zu starten und quasi zu versuchen, die Fähigkeiten zu verbessern. Weil tatsächlich, also da kommt es wirklich auf Nuancen an, manchmal in der System Prompt, wie so ein Agent sich verhält. Ich habe das gestern bei einer Demo, ich habe eine Demo gebaut und wollte halt diesen Agent, dass der diese meine Sub-Agents parallel ausführt und hab dann Ewigkeiten gesessen, irgendwie die System Prompt tausendmal getweaked und dann irgendwann festgestellt, ach, wenn ich von GPT 5.5 auf Cloud Code umsteige, also das Model ändern, funktioniert das alles relativ besser. Und tatsächlich kann man, gibt es da noch für gewisse Probleme andere Models, die besser funktionieren. Da gibt es bestimmt auch viele Storys, die andere haben, wo man sagt, oh, Coding, da benutze ich gerne Cloud Code, aber wenn es darum geht, irgendwelche komplexen Probleme zu analysieren, dann schicke ich GPT 5.5 vor, um mir das alles quasi zu erläutern.

SPEAKER_01 38:02

Du hast vorhin gesagt, bei euch in der Firma hat eigentlich jedes Team mindestens einen Agenten irgendwie am Start für verschiedene Aufgaben. Da hätte ich zwei Fragen noch zu. Zum einen, wie wird so ein Agent bei euch gescoped? Weil es ist ja oftmals eine Entscheidung, so will ich einen sehr spezialisierten Agenten, will ich im Finance-Team einen Agenten, der sich halt optimal in meinem Data Warehouse, was auch immer, auskennt und da Dashboards schrauben kann oder oder oder. Oder will ich halt einen sehr breiten Agenten, der alles so ein bisschen kann, dem ich vielleicht mit ein paar Skills hier und da noch unter den Arm greift, aber ich will mich nicht jedes Mal damit beschäftigen müssen, welchen Agenten ich jetzt frage. Also wie trefft ihr da eine Abwägung?

SPEAKER_03 38:48

Ich glaube, die Best Practice, würde ich sagen, ist es immer auf das Problem zu schauen, welches Problem am besten funktioniert oder welches Problem man so quasi isolieren kann und dafür einen Agenten zu bauen, weil man kann dann dahin gehen und sagen, wenn mein Team irgendwie fünf verschiedene Probleme hat, dann würde ich irgendwie ungern einen Agenten bauen, der irgendwie 100 Tools hat, um diese fünf Probleme abzudecken. Was man besser machen kann, ist zu sagen, okay, ich baue einfach einen Agenten, der mir das eine Problem löst, dem gebe ich dann zehn Tools, die es dafür braucht. Es kann dann mehr effizienter arbeiten und gebe diese fünf Agenten, die ich dann baue, für die fünf Probleme, die setze ich dann als ein Subagent to an Orchestrator. Und dann quasi gibt es dann nur einen Orchestrator, der sich dein Problem anschaut und sagt, oh, der Jan, der möchte das Problem lösen, dann schicke ich mal das Problem zu den Sub-Agent und der Sub-Agent kann dann isoliert mit den wenigen Tools, die es braucht, das Problem für dich lösen. Also am besten Agent Engineering geht auch dahingehend, versuchen, ein Problem zu isolieren, die richtigen Tools zu finden, weil wenn man zu viele Tools einem Agenten gibt, dann hat man dann bläst man den Kontextwindow auf, was man ja auch nicht möchte. Also für Effizienz natürlich immer versuchen, das Problem zu isolieren, die wenigsten Tools dem Agenten zur Verfügung zu stehen, dass es braucht, sodass es nicht viel überlegen muss, was es jetzt machen soll. Die richtigen Skills zur Verfügung stellen, um den richtigen Ansatz zu, dem Agenten Informationen zu geben, wie der richtige Ansatz zum Problem ist. Und dann kann man das skalieren, indem man diese Agenten dann als Subagents an einem Orchestrator anhängt und der kann dann entscheiden, wo es lang geht. Oder man kann so einen Agent dann auch innerhalb von Langraft starten, wo man sagt, okay, ich habe verschiedene Prozesse, die halt sequentiell laufen, wo ich dann sage, okay, ich gehe zu dieser Node oder zu der nächsten Node und dann erst laufe ich, lasse ich den Agenten laufen. Da gibt es quasi sehr viele Möglichkeiten, wie man das dann zusammenbauen kann am Ende.

SPEAKER_01 41:06

Ja, ich denke auch gerade so ein bisschen an unsere Use Cases hier, ne? Wenn wir jetzt allein nur für die Programmierbar gar nicht mal ans große Lotum irgendwie denken, du brauchst jemanden, der die Shownotes macht, jemanden, der vielleicht Recherche vorbereitet, jemand, der die Cover-Assets erstellt und das ist ja auch so. Das könnten alles verschiedene sein, das könnte aber rein theoretisch auch einer sein. Und was jetzt bei Christian rausgehört habe, ist eher so, vielleicht unterschiedliche Agents dafür bauen. Mit gegebenenfalls im einen Orchestrat da drauf, so als, ich sag mal, Convenience-Layer oben drüber, dass ich nicht mit fünf unterschiedlichen reden muss.

SPEAKER_03 41:36

Ist ja im Mächtenleben auch so. Also du kannst natürlich einen haben, der quasi alle mit allem so ein bisschen auskennt oder für jedes Problem irgendwie seinen Spezialisten.

SPEAKER_01 41:48

Ja, richtig, richtig. Und wenn du das gerade schon so schön beschrieben hast, wie ihr das zusammensetzt, dann frage ich mich natürlich auch, wer baut das denn bei euch? Also musst du mir das so vorstellen, dass jetzt euer Finance-Team sich selber hinsetzt und sich überlegt, wie so ein Agent zu scopen ist und dem die Tools an die Hand gibt und sich dann den Orchestrator dazu ausdenkt und und und. Oder ist das immer noch eine sehr technische Challenge, wo tatsächlich dann auch Entwickler mit einem Fachteam zusammensitzen, okay, wir bauen hier mal was für euch und wir machen hier auch die Observability und wir maintainen das quasi auch oder ist da schon ein richtiger Self-Service möglich?

SPEAKER_03 42:25

Wir haben ein Produkt, das nennt sich Fleet und das ist quasi ein Agenten, das ist ein Agent, der Agent baut. Du gehst quasi hin und hast eine einfache Textpromp, wo du sagst, ich brauche einen Agenten, der mir das und das erledigt. Und Fleet hat halt Zugang, kannst du einrichten zu deinen E-Mails, zu deinen Systemen wie Jira oder was auch immer man benutzt und kann dann quasi den Agenten für dich zusammenbauen. Dann klickst du Okay, super, speichern und dann kriegt die Person seinen eigenen Prompt oder seine eigene Seite, wo man dann quasi diesen Agenten prompten kann und der kann dann für einen arbeiten. Also selbst die Leute, die nicht technisch sind, können sehr einfach Agenten bauen, um indem sie einfach nur ihre Integration verknüpfen und dann einen anderen Agenten sagen, hey, bauen wir mal mit meinem Agenten zusammen. Meta-Agent.

SPEAKER_04 43:24

Der dann auch bei euch deployed wird.

SPEAKER_03 43:27

Genau, der wird dann über unsere Plattform deployed, hat sein eigenes Tracing-Projekt. Das heißt, wenn Leute interessiert sind, sich die Traces anzuschauen, können sie das machen. Wir haben auch Lang Langchain Engine haben wir jetzt erst kürzlich released, uh, dass halt dieser Agent, der sich diese Traces automatisiert anschaut und dann, um deine Agenten dann automatisch auch umdatet und verbessert. Das das das geht auch für non, also für Leute, die halt nicht technisch sind. Die können Agenten in der gleichen einfachen Weise auch erstellen.

SPEAKER_00 44:05

Und da ist es mit Human Feedback diese Optimierung oder komplett LLM gesteuert.

SPEAKER_03 44:15

Mit Human Feedback, also wenn es irgendwelche Informationen gibt, die der Agent braucht, dann eher, also entweder bei der Erstellung oder bei der, wenn der Agent noch was ausführt, dann kann der Agent immer einen Interrupt ausgeben und sagen, hey, ich brauche diese Informationen und die kann man dann eingeben.

SPEAKER_01 44:34

Vielleicht ist das ein guter Zeitpunkt, um nochmal über das Geschäftsmodell zu reden. Da hast du nämlich vorhin schon mal kurz drauf abgestellt, dann sind wir irgendwo falsch abgewogen und haben nicht mehr drüber gesprochen. Weil, also Inference ist ja nicht euer Geschäft, sondern die ganze Infrastruktur drumherum, ja, so wie ich das verstanden habe. Das heißt, wie muss ich mir das denn jetzt vorstellen? Wenn ich jetzt meinen Agent mit Langchain bauen will, es heißt, ich bringe meinen eigenen Key mit zu einem Model-Betreiber meiner Wahl und dann bezahle ich bei euch aber noch was und wofür?

SPEAKER_03 45:11

Also am einfachsten Balle bezahlst du nichts, wenn du erstmal nur testen willst. Also man kann immer einen Account erstellen, dort einen Agenten deployen und sehen, was der so macht. Natürlich, wenn es dann irgendwie ins Eingemachte geht und mehrere Agenten bauen will, dann bezahlt man irgendwann für einen Sitz. Aber es gibt Ende des Tages bezahlt man für die Menge der Agenten, die man bei uns laufen lässt, weil die brauchen Compute und das müssen wir natürlich dem Kunden dann in Rechnung stellen. Die Datenmenge an Traces, die wir für Agenten speichern und auch gerade hinsichtlich, wie lange wir diese Daten einbehalten, kostet dann am Ende Geld. Und das ist mittlerweile die zwei großen Einnahmequellen, sagen wir mal. Ich kenne mich jetzt mit dem Pricing, weil ich gehe einfach nur auf die Plattform drauf und kriege alles umsonst, aber ich bin.

SPEAKER_01 46:07

Das ist praktisch, wenn man Mitarbeiter ist, ja.

SPEAKER_03 46:10

Ist immer ein bisschen schwierig, aber ja. Also unsere Haupteinnahmequellen sind meistens im Endeffekt das Deployen der Agents. Viele Leute wollen das auch nicht auf unsere Plattform haben. Die wollen quasi eine Version von Langchain auf ihren eigenen Servern betreiben. Das kostet dann auch nochmal extra die ganzen Geschichten. Oder auch wenn du deine Daten woanders speichern musst. Da gibt es halt viele Modelle, wie du dir das zusammenbauen kannst. Aber generell geht es darum, dann das Bezahlen vom Compute, wenn wir einen Agenten hosten, sowie das Speichern der Daten und das kostet dann.

SPEAKER_01 46:53

Ich glaube, der Vergleich, der sich am ehesten anbietet, ist wahrscheinlich so ähnlich wie bei Vercell. Du zahlst so ein bisschen was pro Seed und danach ist alles von deiner Usage abhängig, was man da so macht. Okay. Vielleicht riskieren wir noch einen Blick in die. Achso, nein, noch nicht. Wir riskieren noch keinen Blick.

SPEAKER_00 47:15

Ne, ich wollte gerade noch einmal, weil du meintest, das andere große ist, das Observability. Und da hast du ja anfangs auch gesagt, es gibt viele Kunden, die ausschließlich diesen Part nutzen. Und ist es hauptsächlich für den Use Case, den Agenten oder das, was rum ist, zu optimieren. Oder ist es auch irgendwie Instant?

SPEAKER_03 47:41

In die Fehler. Also es kann ja, es kann ja bei gerade bei Agenten, die halt relativ länger laufen, kann es halt immer passieren, oh, da wird dann ein Tool-Call falsch ausgeführt und dann passiert das mal bei einem Agenten und dann mal beim zweiten. Und da gibt es ein. Und man will auch nicht immer in die Patterns, also nicht in jeden Trace reinschauen, weil das dann auch relativ viele Daten sind am Ende des Tages. Da gibt es halt dahingehend, dass es halt die unterschiedliche Observability-Plattformen gibt, die halt unterschiedliche Features geben, um zu verstehen, wie so ein Agent funktioniert im Hintergrund. Und viele benutzen halt Observability, um ihre eigenen Datensets zu erstellen, um gleichzeitig auch Evales laufen zu lassen. Ich glaube, Observability und Ewarts gehen öfters Hand in Hand. Ich glaube, da gibt es wenige, die einfach nur ihre Traces zu uns schicken und damit dann auch nichts machen. Also öfters werden dann die Traces dann auch zur E-Walts-Optimierung benutzen. Aber dann müssen die dann nicht unsere Tools vor Evales benutzen, sondern können auch ihre eigenen Tools mitbringen, weil wir am Ende des Tages stellen auch nur diese Datensets bereit und du kannst dann mit deinen eigenen Traces die Datensets erstellen und dann dadurch quasi den Agent testen.

SPEAKER_01 48:59

Okay, also ich dachte mir auch schon während dem Development einfach super hilfreich vor. Wenn du euch daran erinnerst, wie wir unser Agentic Spiel gebaut haben im letzten Game Jam, da haben wir uns ja selber so ein Log für das Tool-Calling im Prinzip eingebaut, um einfach nur zu sehen, okay, du gibst jetzt dem Model was und um so ein bisschen zu beobachten zu können, naja, verhält es dich auch so, wie du das erwartest und benutzt es die Tools, die du ihm gibst, so wie du das irgendwie angedacht hast. Das ist ja vom Deployment auch schon interessant, irgendwie, das zu sehen.

SPEAKER_03 49:25

Ja.

SPEAKER_00 49:27

Und da gibt es da dann noch irgendwas, was ihr automatisiert oder mit AI anbietet, um das zu evaluieren und zu optimieren, oder ist es erstmal nur die Sammelschicht?

SPEAKER_03 49:38

Wir sammeln die Daten und bieten dir die Agenten an, um quasi über die Traces zu schauen, um verschiedene Patterns zu finden und sagen, hey, bei dem Toolcall sendet dir die Agent manchmal falsche Informationen und dann die Lang Smith Engine kann dir dann auch gewisse, zusätzlich dann sagen, wenn du das änderst in deinem Agent, dann sollte der besser laufen. Und dann kann man sagen, okay, ich möchte diese Änderung an 10% meiner User ausgeben und zu sehen, ob das tatsächlich dann auch Verbesserungen zeigt.

SPEAKER_04 50:19

Dann schauen wir jetzt in die Glaskugel. Wenn das dein Wunsch ist.

SPEAKER_01 50:24

Du hast eben schon gesagt, Christian, dass so Identity gerade eines der großen Challenges ist, mit der ihr euch beschäftigt, weil das immer relevanter wird bei dem kollaborativen Einsatz von Agenten. Was sind denn so danach oder darauf aufbauend so die nächsten großen Hürden, die ihr so antizipiert?

SPEAKER_03 50:48

Das ist eine gute Frage. Ich glaube, es kommt immer darauf an.

SPEAKER_01 50:51

Endlich eine Stunde später und wir haben es geschafft, die erste gute Frage zu stellen.

SPEAKER_03 50:56

Also die Sache, also ich kann ja heute sagen, okay, das ist morgen das große Thema, aber dann ist auch schon wieder übermorgen und in unserem, in dem Feld, im AI-Bereich, ändern sich auch so viele. Also wenn man einfach nur mal sechs Monate zurückgeht, dann hätte ich nicht gedacht, wo wir jetzt heute stehen. Und ich glaube, was in der Zukunft interessant werden kann, wo wir ein spannendes Feld sehen, ist die Open Rates Models, die mittlerweile immer besser wären. Ich kann mir nicht vorstellen, dass jede große Organisation irgendwie hunderte von tausend Euros an Anthropic oder OpenAI jeden Monat überweist, um gewisse Agenten laufen zu lassen. Dahingehend ein spannendes Feld, wie man diesen Open Weights Models für sich selber tunen kann und für sich selber aufbauen kann, um halt, also ich kann sehen, dass jeder später, jeder Agent wird später vielleicht sein eigenes getuntes Model kriegen, das basierend auf dem Open Weight Model, das auf dem Open Weight Model basiert, das durch die Daten, die eine Firma so aufnimmt, trainiert wird oder gefeintuned wird und dadurch wirklich super funktioniert für den Use Case, für den das Model gebaut wurde, aber nicht für andere Model. Also diese generellen Models, die Frontier-Models, ich glaube, das wird irgendwann in den nächsten Monaten zurückgehen und die Open Race Models werden bald immer mehr Popularität finden, gerade im Kostenbereich, aber auch in einer Hinsicht, wie man das dann auch selber tunen kann. Gerade wie wir unsere eigenen Agenten bauen, kann man vielleicht in der Zukunft die Models einfacher tunen und für seinen Use Case aufbauen. Ohne Nvidia oder anderen Firmen irgendwie Tausende von Euro für Grafikkarten zu bezahlen, sondern da gibt es wahrscheinlich, werden mittlerweile schon Firmen aufgebaut, die sich auf solche Services spezialisieren.

SPEAKER_01 53:00

Da meine Frage vielleicht an euch beide, weil wir das ja in den letzten paar Monaten ja auch schon immer wieder gehört haben, diese Open-Waite-Models, die so am Aufholen sind. Und ganz oft wird dieses Kostenargument, Christian, was du auch gerade angeführt hast, genannt, Firmen wollen sich so ein bisschen unabhängiger von ihrer Rechnung an OpenAI oder wen auch immer machen. Aber am Ende brauchst du ja trotzdem Inference. Also es ist ja egal, in Anführungszeichen, wessen Model ich benutze, aber irgendwo muss ich es ja trotzdem ausführen oder ausführen lassen. Also irgendjemand lässt sich das ja am Ende des Tages trotzdem bezahlen und irgendjemand braucht trotzdem teure GPUs dafür. Kann das wirklich so ein großes Argument sein, auf ein offenes Modell zu wechseln, nur weil ich da, nur weil ich da Geld spare? Weil auch die offenen Modelle müssen ja, also zum einen, wie gesagt, betrieben werden, aber auch ja erstmal entwickelt werden. Auch das muss ja irgendjemand nachhaltig finanzieren können. Und ich frage mich bei dieser Argumentation immer, ist das, also ist das wirklich so einfach zu sagen, ich gehe jetzt auf mein, was das neueste, Kimi, Gwen, keine Ahnung so, ich nutze jetzt eins von denen und dann wird meine Rechnung nur noch ein Bruchteil sein von dem, was es vorher war.

SPEAKER_03 54:06

Willst du zuerst anbauen, Dennis?

SPEAKER_00 54:11

Ja, also ich meine, ob man es sicher sagen kann, aber zumindest für mich deuten alle Trends dahin, dass es so sein wird. Also erstens, weil du es auf Hardware, die jetzt nicht irgendwie H200 irgendwas ist oder sowas laufen lassen kannst, sondern jetzt schon in Bereichen bist, wo du vernünftige Ergebnisse von mir aus auf deinem M5 MacBook oder sowas erzielst. Das ist das eine. Weil wir zweitens sehen, dass dauerhaft Optimierung auch in der Inference sind und mit wie viel weniger Power man auch solche großen Modelle teilweise laufen lassen kann, gerade wenn das dann für auch noch diese Open Weights Modelle optimiert ist. Ja, und so, dass da ist ja eher mein Tag, ich habe ja gelernt in unserer Diskussion, dass ich vielleicht eher darauf gehe, zu sagen, okay, ich kann mir nicht vorstellen, dass Exorbiter teuer wird, so, vielleicht eher bei der Aussage zu bleiben, ich kann mir vorstellen, dass die Intelligenz, die wir aktuell haben, teurer wird. Es kann passieren, dass irgendwie du noch mehr willst und es sinnvoll ist, noch mehr zu, also mehr zu nutzen davon, aber auch nur, wenn damit einhergehend dein Benefit, dein Output, den du hast, ebenso skaliert. Und dann ist es auch wirtschaftlich wieder sinnvoll. Dann kannst du auch von mir aus 100.000 Euro im Monat ausgeben, wenn du irgendwie den Benefit davon hast. Aber dass halt so der Preis für Intelligenz, den sehe ich halt nicht, dass der da steigt. Und von daher, ja, glaube ich schon, dass das auch ein Kostenargument ist und wo man schon sieht, das wird in einem Rahmen sein, der okay ist.

SPEAKER_03 55:46

Christian? Ich stimme dem zu. Auch aus wissenschaftlicher Sicht, glaube ich, Anthropic und OpenAI wollen ja auch keine Milliarden von Dollar ausgeben, um diese Models zu trainieren. Ich glaube, viel Research geht auch gerade dahingehend, wie kann man solche Models trainieren in immer einfachen Formen, immer optimisierter, dass man relativ schnell mit wenig Compute gute Resultate erzählen kann. Und dahingehend glaube ich, dass es in der Zukunft möglich sein kann, diesen Use Case zu betreiben. Und auch wenn man, sagen wir mal, Firmen wie Fireworks benutzt, um Models zu Feintunen, es braucht ja nur ein bisschen, aber wenn man dann halt ein Open Source oder OpenWay-Model Fintuned mit ein bisschen, wenn man da ein bisschen Geld reinsteckt und dieses Feintuning kann alleine schon den Unterschied machen, gerade für, wenn man das Model für einen gewissen Use Case innerhalb einer Firma benutzt. Und wenn man dann das da hingehen kann und sagt, ich nehme das Model und laufe das halt, lasse das halt nur über meine Firma laufen, dann hast du halt auch nicht die Probleme, wie, werden meine Daten benutzt, um das Model zu turnieren. Das ist auch gerade, warum ich noch nie bis jetzt, seit den letzten drei, vier Wochen. Fable konnte ich noch nicht benutzen, weil Fable, die diese Data Disclosure hat, dass man nicht ausstellen kann, dass sie die Daten, die Fable einzieht, fürs Turnieren benutzen. Das konnte, durfte ich durch meine Firma diese Policy, dass wir das nicht machen können. Daher konnte ich auch noch nicht Fable benutzen. Und sowas gibt es halt, wenn man in die Massenadoption schaut, dann wird es viele Firmen geben, die das damit auch nicht eingehen und die werden dann auch ihre eigenen Open Rate Models benutzen.

SPEAKER_04 57:40

Ich hatte eine Frage unterbrochen mit meiner Geldfrage. Vergessen. Okay. Ich glaube, er hatte gerne, oder? Habe ich schon irgendwas ausgesprochen?

SPEAKER_01 57:52

Nein, nein, ich hatte doch irgendeinen von euch gerade unterbrochen, weil ich gedacht habe. Achso, ja genau, wir waren ja gerade bei Christian mit, was sind so die Tendenzen, die wir so in Zukunft ändern, dann sind wir bei OpenBeucht mal hängen geblieben. Okay.

SPEAKER_03 58:06

Aber ich glaube dahingehend, dass es, dass wir das Entwickeln von Agenten wird immer einfacher sein. Wie gesagt, mittlerweile hast du diese No-Code-Tools wie Langchain Fleet, wo du einfach nur eine Prompt eingibst und eine Agent wird für dich erstellt. Es ist immer interessant, wenn ich dann mal meine Freunde in Sachsen-Anhalt besuche, wenn ich mal nach Hause fahre und dann frage, die arbeiten dann bei Siemens oder LVW und dann frage, was macht ihr so mit Agenten? Und da kommt dann halt noch nicht viel raus. Ich glaube, da gibt es noch eine Riesenkurve von Firmen, wo die halt erstmal anfangen, AEI zu benutzen und sich damit erstmal auch einstellen, diese Workflows über Agenten laufen zu lassen. Und ich glaube, da gibt es eine Menge Arbeit oder eine Menge Agenten, die gebaut werden müssen, bis wir in einem mehr intelligenten Zeitalter leben können.

SPEAKER_01 59:00

Das wäre eine spannende Frage. Da haben wir ja vorhin bei Mittagessen für ja auch drüber gesprochen, so wer nutzt es eigentlich gerade schon wie viel, wenn du jetzt sagst, okay, die deutsche Großkonzerne kann ich mir vorstellen, dass die jetzt noch nicht so ganz vorne mit dabei sind, Agenten irgendwie zu nutzen. Aber hast du so ein Gefühl dafür, da gibt es da vielleicht so klare Trends, wen ihr so in eurer Customer Base seht, wer da am motiviertesten ist?

SPEAKER_03 59:26

Wir haben tatsächlich, also es ist wenig, es ist weniger, geht es darum, was die Firma macht, sondern mehr darum, wo die Firma ihren Hauptsitz hat. Also alle Firmen, die so in unserer Silicon Valley-Blase sich befinden, die von A bis Z sind alle dabei, die versuchen irgendwie auf diesem Pferd aufzuspringen. Also mittelständische Unternehmen aus anderen Bereichen, in anderen Regionen der Welt, da ist es halt wahrscheinlich noch nicht so ganz angekommen. Ist halt auch irgendwie so eine Blase, in der wir hier gerade drüben leben.

SPEAKER_04 1:00:12

Müssen wir noch ein bisschen die Werbetrommel rühren. Ja.

SPEAKER_00 1:00:17

Also, oder Blase kann man ja auch durchaus negativ sehen im Sinne von, dass sie irgendwann platzt, aber ich glaube, du meinst eher den eingegrenzten Kreis an Menschen, der da den Zug auf hat. Und da sehen wir uns ja irgendwo auch ein bisschen, dass wir da einigermaßen ab.

SPEAKER_01 1:00:38

Spirituell sind wir quasi im Silicon Valley. Genau. Von der Wetterau ans Golden Gate. Ja. Cool. Dann, wenn Dennis keine Fragen mehr hat, ist unsere standardsetzte Frage unser Gast immer, Christian, welche Frage haben wir dir nicht gestellt? Auf welches Thema warst du ultra vorbereitet, wolltest unbedingt drüber reden und ärgerst dich jetzt, dass dich keiner danach gefragt hat?

SPEAKER_03 1:01:06

Eigentlich, ich bin heute Morgen aufgewacht, um ich bin heute um 5.30 Uhr aufgewacht, um hier heute am Start zu sein. Da konnte ich noch nicht so viel überlegen, welche Frage mir gestellt werden sollte. Ich war einfach froh, dass ich mal wieder ein bisschen Deutsch reden konnte.

SPEAKER_01 1:01:24

Happy to be of service. Vielleicht ist die Taktik für uns in Zukunft, einfach unsere Gäste früh überrumpeln. Dann können sie nicht so mit so viel Hintergedanken hier aufschlagen.

SPEAKER_00 1:01:35

Sehr gut.

SPEAKER_01 1:01:36

Wunderbar. Dann sind wir mit dem regulären Teil der Sendung quasi durch. Und was bleibt uns noch? Die Picks of the Day. Wunderbar. Und du hast die Musik nicht angemacht. Tim, dim, dim, dim, dim. Ja, post-right-Musik. Post-Ride Musik endet hier. Wunderbar. Dann würde ich sagen, Christian darf anfangen, weil er Gast ist und ich mich sehr auf seinen Pick freue.

SPEAKER_03 1:02:03

Mein Pick of the Day ist die Show Silicon Valley, die ich gerade auch einmal geebincht habe, weil ich finde, dass das für mich irgendwie gerade teilweise auch ein bisschen Realität ist und interessanterweise ist auch irgendwie jede Staffel von Silicon Valley bildet auch immer einen eigenen Lebenszyklus einer Firma hier im Valley ab. Und da wollte ich ja herausfinden, in welcher Season ich gerade mich selber befinde. Oh, spannend. Und dahingehend war das für mich in den letzten zwei, drei Wochen ein Spaß mir, die Sendung nochmal einmal komplett durch anzuschauen.

SPEAKER_01 1:02:45

Sehr gut. In welcher Season befindet sich Langchan jetzt gerade? Das ist vielleicht eine spannende Erkenntnis jetzt noch.

SPEAKER_03 1:02:52

Ich glaube, ich weiß nicht mal genau, in welcher Season sie in ihrer eigene große Firma mit den ersten Entwicklern so, also raus aus Bugmans kleiner Hütte. Aber da sind wir jetzt, wo wir unsere eigene Firma, die eigene Firma haben mit den ersten Leuten und den Sales-Leuten, die anfangen, die Sachen zu verkaufen und die Dinger groß zu machen.

SPEAKER_01 1:03:15

Das ist ja eigentlich so, du hast Silicon Valley nie geguckt, oder? Nee. Also es ist eigentlich so lustig, weil in den späteren Seasons haben sie ja auch diesen AI-Agent Anton, der in der Garage, am Anfang wohnt er in einem Serverreck in der Garage und irgendwann, wenn sie dann eine eigene Firma haben, wohnt er im Keller im Serverreck. Und der wird ja quasi wie so ein eigener Protagonist auf so einer Meta-Ebene dadurch. Und deshalb ist es vielleicht schon halt irgendwie auch noch super passend, dass das.

SPEAKER_00 1:03:40

Ja. Aber mir ist gerade wieder eine Frage, die ich mir schon jetzt häufig auf der Zunge wollte. Ich wollte noch dich persönlich fragen im Sinne von, wie stressig ist dein Job aktuell? Weil zumindest ist es ja so, ne, also ich meine, es ist ja ein Bereich, wo sich wahnsinnig viel ändert. Und wenn man dann auch noch irgendwie Infrastruktur bereitstellt und Dinge und Tools bereitstellt, die in diesem Bereich drin sind, dann ist es ja nochmal irgendwo so ein Faktor zeitkritischer irgendwie. Also wie stressig empfindest du deinen Job aktuell?

SPEAKER_03 1:04:11

Schon stressig, also ich habe immer meinen Job als Hobby angesehen, weil anders hätte ich das irgendwie nicht ausgesucht, hier rüberzukommen, wo man dann tatsächlich versucht optimieren, dass man jede freie Sekunde, die man hat, irgendwie sich an die Arbeit setzt, weil das für mich irgendwie ist so ein wie so ein Anno 1503-Strategiespiel, wo man immer was zu tun hat und irgendwie immer antworten kann und sich immer versuchen, sich irgendwie weiter auszusetzen. Ich merke mittlerweile, ich bin ja jetzt auch schon 37, dass es tatsächlich, ich kann so viel Zeit reinstecken, wie ich will, ich werde nie fertig sein. Ich werde immer jüngere Leute haben, gerade die AI-Natives, wie wir sozusagen, wie wir sie nennen, die können mit der in II-Tools tatsächlich natürlicherweise besser umgehen als die wir, die wir schon irgendwie noch händisch programmiert haben, sagen wir so. Also es gibt immer mehr zu tun. Stressig wird es dann, wenn man tatsächlich irgendwie diese Deadlines hat und Sachen abliefern muss und dann Sachen nicht funktionieren und viele Sachen gleichzeitig balancieren muss. Aber dahingehend gibt es dann auch, wo man dann am Wochenende dann auch mal abschalten kann und dann so ein Glas Weizen trinken kann, auszuhalten, aber deswegen geht man auch hier rüber, um so diesen Spaß mitzumachen. So die 9-5-Jobs gibt es halt hier leider nicht.

SPEAKER_01 1:05:35

Und einen Weizen kriegst du, aber? Ich wollte gerade sagen, stell dir vor, du bist in Amerika und kriegst nur ein amerikanisches Weizen.

SPEAKER_03 1:05:40

Nee, hier gibt es Paulana und ja, hier gibt es Paulana und die deutschen Hefeweizen gibt es hier schon.

SPEAKER_01 1:05:46

Schau mal was. Not all is lost. So, ja.

SPEAKER_03 1:05:50

Das einzige Problem, was es hier nicht gibt, ist so ein guter Döner. Den gibt es in der ganzen Bayer ja nicht. Wir haben schon, ich hab mal mit einem Point und dann Malte von Besser, der CTO, der wohnt ja auf der anderen Seite der Brücke in Oakland. Wir wollten schon mal so einen deutschen Stammtisch aufbauen, mit wo wir uns an dem besten Döner in Oakland treffen, regelmäßig. Das hat noch nicht geklappt, weil es, glaube ich, der Döner auch noch nicht ganz so gut ist. Wenn ich die nächste Mal zwei Tage habe.

SPEAKER_00 1:06:20

So eine Million-Dollar-Idee, Döner aufmalen im Sitic Valley.

SPEAKER_03 1:06:23

Genau, also das, ich will es mal selber versuchen, mir das Stück Brot zu backen, so auf so ein türkisches Brot und dann so einen Döner zusammenschustern, sollte ja nicht so schwer sein. Aber tatsächlich, wenn es jemanden da draußen gibt, der guten Döner bauen kann, und den hier dann irgendwie für 10 Dollar verscherbeln könnte, das würde mir mich freuen und jeden, der hier als Deutscher im Silicon Valley lebt. Glückmarter haben wir schon, jetzt fehlt nur noch der Döner.

SPEAKER_01 1:06:51

Sehr gut. Also ich meine, wir haben ja, wir kennen ja bei der Programm, wir haben schon so ein paar Leute, die im Valley arbeiten. Vielleicht ist das jetzt der Aufruf hier für Dönerempfehlungen in und um San Francisco an uns.

SPEAKER_00 1:07:02

Und wir erreichen es dann weiter. Oder wenn es ihn nicht gibt, wie gesagt, dann ernst gemeinte Menschen, die motiviert sind, dort ein Döner.

SPEAKER_01 1:07:07

Wobei ich dann, also da würde ich jetzt schon meine Hand dafür ins Feuer legen, dass niemand im Valley Döner für 10 Dollar verkauft. Sondern für 15. Ja, oder halt für 20 oder 25 oder keine Ahnung. Aber ich glaube, diesen Preispunkt, Chris. Ich weiß nicht, wann du das letzte Mal hier in Deutschland einen Döner gegessen hast, aber Dönerpreise sind auch sehr inflationär. Wie sieht denn der Döner-Endex bei euch gerade aus? Also hier in Bad Nauheim sind wir bei 9 Euro. Ja, und das sind ja schon mehr als 10 Dollar. Und da bist du noch nicht im Valley. Das stimmt. Okay.

SPEAKER_03 1:07:35

Hat das manchmal 5 Mark gekostet?

SPEAKER_01 1:07:37

Ja, das ist schon ein bisschen her.

SPEAKER_00 1:07:42

So, Moment mal, so alt bist du auch. Was hast du gesagt, 37? Ja. Da hast du Döner nicht in D-Mark bezahlt, oder?

SPEAKER_03 1:07:51

Auf dem Gymnasium. Auf dem Gymnasium hat er, glaube ich, damals 2,50 gekostet. Hast du recht, ja.

SPEAKER_01 1:07:58

Okay, Dennis hat mit seiner Zwischenfrage genug Zeit geschindet, jetzt ist er fällig. Was ist dein Pick of the Day?

SPEAKER_00 1:08:03

Ja. Den gibt's, den Pick. Technologisch schaue ich jetzt mal richtig was raus. Okay, es ist ein sehr, es profitiert ein sehr kleiner Nutzerkreis von meinem Pick jetzt. Und zwar die, die Kinder haben in einem Alter, die noch nicht alt genug sind, ein eigenes Smartphone zu haben und trotzdem schon alt genug sind, um alleine zu Hause zu sein. Und da ist irgendwie so ein Gap, wo man dann vielleicht nach Erreichbarkeit und sowas guckt. Und dann so eine Alexa zu Hause zu haben, wo man einfach mit so einem Sprachbefehl dann im Notfall mal anrufen kann oder sich melden kann, ist sehr viel wert.

SPEAKER_01 1:08:52

Also wir lassen jetzt hier einfach mal unter den Tisch fallen, dass du vor unten eine Stunde mit deinem Kind telefoniert hast und deshalb aus irgendeinem Grund die Inspiration dazu hattest. Aber ich muss sagen, wir haben ja auch so ein Setup zu Hause, das funktioniert tatsächlich sehr gut. War das vorhin hier ein Videocall? Ja. Mit so einem Echo-Show-Dingsbums.

SPEAKER_00 1:09:10

Ja, Echo, nee, Dot ist es leider. Ja, aber ein relativ altes Ding. Aber ja, irgendwas mit Display und Kamera, ja.

SPEAKER_01 1:09:16

Ja, weil das hat tatsächlich bei uns auch den Unterschied gemacht. Also wir hatten schon diese Echo-Dots, die nur so Stimme machen. Aber ich glaube, ich weiß nicht, ob das so ein kognitives Ding ist, aber es hilft für Kinder, wenn sie halt irgendwie sehen, mit wem sie reden. War so mein Eindruck. Und dann ist es auch besser geworden. Und es ist natürlich auch cool, weil du kannst es ja auch so rum anrufen. Ja. Und je nachdem, wie du das einstellst, per Drop-In geht das ja auch schon direkt an, ohne dass sie abheben müssen, in Anführungszeichen. Und dann ist es natürlich auch einfach cool, schon mal zu sehen, so was da gerade eine Sache ist.

SPEAKER_00 1:09:45

Ich habe ja irgendwie, ich habe da noch nicht so viel in den Einstellungen geguckt. Bei uns ist es immer noch so verschwommen, mein Bild. Ich sehe schon irgendwie, dass es da ist, aber erst wenn dann jemand mit dem Gesicht davor geht, dann wird es, glaube ich, erst scharf gestellt. Aber ich kann schon rufen, so von wegen. Ja, man hört dich auf jeden Fall schon.

SPEAKER_05 1:09:58

Komm her.

SPEAKER_00 1:09:59

Okay. Ja, also von daher, da ich keine andere Erfahrung habe, wird es wohl Alexa jetzt erstmal sein.

SPEAKER_01 1:10:06

Ja. Als Aspekt. Wunderbar. Und bei zehntausenden Leuten geht jetzt gerade, wo du das laut im Lautsprecher gesagt hast, haben sie auch gedacht, das geht ja nicht mehr.

SPEAKER_00 1:10:17

Alexa, kauf eine Packung Haargummis auf Amazon.

SPEAKER_01 1:10:23

Hättest jetzt auch schon ein Programmierkon-Ticket kaufen lassen können oder so. Sehr gut. Wunderbar. Mein Pick of the Day ist was ganz anderes, was ganz Technisches und nichts, was mit dieser Folge zu tun hat. Ich habe tief in meiner Pickkiste gewühlt und habe Setservers.com gefunden. Das ist eine Webseite für alle, die sich so ein bisschen um Operations, Infrastruktur, Server-Themen gerne kümmern. Und zwar kann man da an so kleinen, aber feinen Aufgaben lernen, wie man so Server in Production debuggt. Setservers.com, traurigeserver.com, du gehst da drauf, du kriegst eine, es dauert ein paar Sekunden, dann fährt wirklich so eine kleine VM-Setbox hoch und du kriegst ein kleines Problem gestellt. Also hier ist ein Log-Overflow, finde den Prozess, der daran schuld ist, terminiere den Prozess, aber lass das Lok irgendwie bestehen, bla bla bla. Und das ist so zu ein bisschen üben, eigentlich mal ganz nett. Jetzt springt Dennis gleich wieder von der Seite ein und sagt, das macht doch deinen Infrastrukturagent irgendwie alles bald. Und da muss man sich gar nicht mehr drum kümmern. Das ist wahrscheinlich richtig, aber ich behaupte immer noch, es gibt so ein paar Basics, das ist ganz gut, wenn man die mal verstanden hat. Und wenn man nicht am eigenen Server üben und experimentieren will, ist setserverscom eine kleine, aber feine Zwischenübung. Die sind gar nicht so groß, die Sachen, die kann man sich bei einer Mittagspause ein paar Minuten ein oder zwei anschauen und dann ein bisschen Fingerspitzenübungen machen. Sehr gut.

SPEAKER_03 1:11:49

Wie viele Leute mögen es noch an Servern rumzufursteln oder wie viele sagen einfach, schmeiß den Server runter, ich starte mir einen neuen?

SPEAKER_01 1:12:01

Auch das habe ich schon gemacht, wenn man, weiß nicht, wenn es ein größeres Update oder sowas ist. Ich meine, er hat ja auch in den letzten paar Jahren so Entwicklungen wie Docker oder sowas mega viel dazu beigetragen, dass ein sehr großer Teil von einem Setup einfach ultra portabel geworden ist und der Server selbst gar nicht mehr so eine große Rolle spielt. Also bei mir laufen auch nur noch Docker-Container und wenn ich mit der Kiste nicht mehr ganz zufrieden bin, dann wird die halt weggeschmissen, neue provisioniert und die ganzen Container da wieder hochgefahren. Das ist ja schon gar nicht mehr so wichtig. Aber wie gesagt, viele von diesen Übungen, gerade dieses Logding, das ist ja unabhängig von der eigentlichen Infrastruktur, das kann man sich auch so mal anschauen. Und irgendwo müssen die Kinder von heute ja auch irgendwie Bash und sowas alles lernen. So.

SPEAKER_02 1:12:42

Das stimmt.

SPEAKER_01 1:12:45

Wobei, ich weiß nicht, du hattest heute mit den Studenten die Einführung gemacht. Lernen die überhaupt noch Bash? Oder schon, ich weiß nicht. Schon? Ja, vielleicht. Who knows? Wunderbar, damit sind wir durch für heute. Uns bleibt nicht viel zu sagen, außer danke, Christian, für die Zeit. Danke, dass du so ultra früh aufgestanden bist, deiner Ortszeit nach und die Zeit für uns genommen hast. Es war super interessant. Danke, Dennis, dass du da warst. Und wenn ihr Fragen, Anregungen, Kritik habt, dann immer gerne an Dennis.programmier.bar. Lob immer gerne an was. Dave. Dave wollten wir auch einrichten. Gibt es auch jetzt schon, ja. Gibt es jetzt schon Lob bitte gerne an Dave dann oder so. Und ansonsten könnt ihr uns auch auf Social Media schreiben, überall da Nachrichten hinterlassen, wo ihr uns hört oder seht. Wir lesen alles, was ich mit. Und wir verabschieden uns. Bis nächste Woche.

SPEAKER_00 1:13:40

Vielen Dank, Christian.

SPEAKER_01 1:13:42

Danke dir. Ciao, ciao. Tschüss.