Deep Dive 209 – AI Libraries mit Christopher Hertel

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

In diesem Deep Dive sprechen Jan und Garrelt mit Christopher Hertel, Head of Technical Program bei der AMCS Group und Speaker, über die Entstehung und Funktionsweise von Symfony AI, einer PHP-basierten AI-Library, die sich auf Inference und Agent-Tools spezialisiert. Die Crew diskutiert dabei nicht nur das Projekt von Christopher, sondern bespricht auch ganz allgemein, welchen Zweck AI Libraries erfüllen, wo sie an ihre Grenzen stoßen und wo die Reise hingeht.

Christopher erklärt, dass Symfony AI sowohl eine Abstraktionsschicht für unterschiedliche AI-Provider bietet als auch Datenobjekte strukturiert verarbeitet, wodurch Entwickler:innen unabhängig vom jeweiligen Anbieter arbeiten können. Dabei liegt der Fokus auf Extension Points, die Entwickelnden maximale Flexibilität bieten, ohne dass die gesamte kognitive Logik ausgelagert werden muss. Die Library ist darauf ausgelegt, Framework-agnostisch zu sein, und lässt sich auch in anderen Umgebungen einsetzen.

Christopher spricht außerdem über die Herausforderungen, ein Open-Source-Projekt zu warten: Testbarkeit, nicht-deterministischer Output und die Integration zahlreicher Provider. Symphony AI nutzt Docker-basierte Integrationstests, um verschiedene Komponenten wie Vector Stores und Streaming-APIs zuverlässig zu prüfen. Besonders wichtig sind dabei praxisnahe Beispiele, die von Markdown-Dateien bis hin zu Query-Implementierungen reichen, damit Nutzer:innen die Architektur der Library nachvollziehen und ausprobieren können.

Die drei sprechen außerdem über die Nutzung von Coding-Agents bei der Entwicklung der Library selbst und überlegen, welchen Zweck und welche Anforderungen eine Library in Zeiten der agentischen Softwareentwicklung tatsächlich erfüllen muss.

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_03 0:06

Hallo und herzlich willkommen zu einem neuen Deep Dive hier in der Programmierbar. Ich bin wie immer für euch der Jan und neben mir in der linken Sofa-Ecke sitzt der Gerät. Du bist gar nicht in der linken Ecke, du bist in der rechten Ecke. Nee, von mir schon in der linken. Ja, ja. Also von mir so. So meine ich das ja auch. So meine ich das auch. Und wir haben mit uns im virtuellen Studio heute den Christopher Hertel. Hallo Christopher, schön, dass du da bist. Hi, danke für die Einladung. Christopher, du bist nicht ohne Grund hier. Du bist ein sehr cool. Müsste das hätten wir vielleicht früher im Vorgespräch erwähnen sollen oder so. Christopher ist ein sehr gefragter Speaker und das nicht nur, weil er auch auf der Programmierkonf war letztes Jahr. Sondern weil er sich auch auf sehr vielen anderen Konferenzen rumtragt. Christopher, ich habe vorhin mal versucht, nachzuschauen. Ich habe es nicht 100% rekonstruieren können, aber ich glaube, wir haben das erste Mal gemeinsam 2019 auf der Bühne gestanden. Auf der Symphony Live in Berlin. In Berlin? Ah, okay. Das sind Fantasien.

SPEAKER_02 1:09

Ja, da war das stimmt. Ich wusste es mal früher. Ich hab's aber in meiner Camera-Roll einfach nicht mehr gefunden. Ich bin vorhin so in der Mittagspause so am Handy einfach stupide, stundenlang gescrollt und dachte so, wo waren wir da gemeinsam?

SPEAKER_00 1:24

Aber ihr kennt doch schon, also ihr kennt euch seitdem. Also ihr habt euch da getroffen und gequatscht miteinander.

SPEAKER_03 1:28

Also den Christopher kannst du eigentlich nicht kennen, wenn du dich irgendwie in der deutschen PHP-Community.

SPEAKER_00 1:33

Das verstehe ich, ja. Also ich kannte ihn schon, bevor ich ihn kannte, sozusagen. Okay. Aber ich meine, ob du ihn kennst oder ihr euch kennt, ist ja noch ein großer Unterschied.

SPEAKER_01 1:43

Ich glaube, bei der Fantasiland war das so, dass es einen Raum nur gab für die Talks und da schaut man sich natürlich schon alle an. Das heißt, Jan Gregor war damals sogar vor mir noch dran. Das heißt, ja.

SPEAKER_02 1:53

Und ich war nicht schlecht genug, als dass er nicht in der Zeit hätte, lieber Achterbahn gefahren oder so. Das ist ja eigentlich das Kompliment, also. Aber das weiß er vorher nicht. Also kannst du auch jedes Kompliment zunächst tun.

SPEAKER_00 2:05

Wenn du dich selbst komplimentierst, dann so. Ladet das ein.

SPEAKER_03 2:11

Wir wollen heute sprechen über AI Libraries. Und zwar haben wir deshalb auch den Christopher eingeladen, weil Christopher maßgeblich mitverantwortlich ist für das Symphony AI Library und das sich quasi hervorragend anbietet, um darüber zu sprechen und darüber so ein bisschen Allgemeineres vielleicht auch abzuleiten. Aber bevor wir tief ins Thema einsteigen, Christopher, vielleicht kannst du einmal ganz kurz, also ganz kurz geht es wahrscheinlich nicht, weil es schon ein bisschen größere Nummer abreißen. Was ist Symphony AI? Was habt ihr euch dabei gedacht und was ist so der aktuelle Stand?

SPEAKER_01 2:44

Klar. Symphony AI ist tatsächlich ein Projekt, was anfängt mit einer niedrigen Ebene. Wir haben so Foundational Components. Grob gesagt, ist ja erstmal ein Satz an unterschiedlichen PHP-Komponenten, um AI-basierte Feature in PHP-Anwendungen zu bauen. Ist, glaube ich, so ein bisschen basiert auf diesem Game Changer der API-basierten Inference. Dadurch, dass wir jetzt über HTTP-APIs Models ausführen können bei, eigentlich hat ja jeder Anbieter inzwischen solche APIs, haben wir natürlich auch die Möglichkeit, sowas gut in PHP zu machen. Und wir haben so Foundational-Komponenten, die eher dafür da sind, eine Abstraktionsschicht reinzuziehen für Inference, für Vector Stores und vielleicht auch so ein bisschen andere Integrationen, wie zum Beispiel Agent Tools. Und dann haben wir so ein Mid-Level, würde ich sagen, was wirklich dann so Agent-Komponente ist oder Chat. Und dann natürlich Symphony-Framework Integration, ist ein Opt-in. Symphony versuchen wir immer relativ agnostisch, framework agnostisch zu bauen, dass man auch dann, wenn man, wenn man, weiß ich nicht, in Drupal unterwegs ist oder mit Level unterwegs ist, auch Symphony AI nutzen kann. Soweit so das Grobe, würde ich sagen.

SPEAKER_03 4:03

Okay. Und dann lass uns doch das vielleicht direkt als Einstieg so nutzen. Du hast ja schon angesprochen, dass so Inference als API so der große Game Changer dafür war und ja im Prinzip auch ein Requirement, dass es diese Libraries auch irgendwie alle geben kann. Und da will ich vielleicht mal die ketzerische Frage zum Eingang stellen. Oh ja. Also, was macht denn dieses Library am Ende aus, außer so ein sehr dünner Rapper, um Curl zu sein? Wenn man sich diese ganzen API-Dokumentation von OpenAI oder Entropic oder sowas anguckt, ne, dann ist das ja auf den ersten Blick wirklich nicht viel mehr als, naja, mach da halt mal so einen Post-Request irgendwie hin und dann kriegst du schon irgendwas in Furitas zurück. Wieso brauche ich denn da überhaupt ein Library?

SPEAKER_01 4:52

Du hättest die Frage noch ketzerischer stellen können, wenn du sagst, warum kann ich denn nicht einfach Light LM nehmen? Weil das ist ja sozusagen so ein Proxy, der alles wegabstrahiert. Aber es ist fair, also tatsächlich die Value Proposition für uns ist bei der Foundation-Komponente die Abstraktion. Das heißt, ich will meinen Anwendungscode so bauen, dass, egal ob ich das jetzt mit Vertex AI oder mit Hugging Face oder Gemini, Anthropic, you name it, mache, dass ich den Code an sich nicht anders machen muss, sondern nur die Konfiguration dazu. Und das ist erstmal nur ein Wrapper um die HTTP-API. Und das zweite Feature, was wir eigentlich reinbringen, ist eine Strukturierung durch Datenobjekte. Das heißt, du musst an der Stelle jetzt nicht Arrays oder JSON durch die Gegend werfen, sondern du kannst sagen, ich habe hier meine Message, ich habe hier mein Image oder mein PDF und das wirfst du rein und das bauen wir dann durch so einen Serializer in die JSON-Dokumente um. Ist aber tatsächlich erstmal ein bisschen schlanker und dann, nervig hätte ich fast gesagt, aber der komplexere Teil ist dann sowas wie Streamhandling. Und das ist tatsächlich was, wo es dann losgeht, wo du vielleicht dann doch weniger Bock hast, das selber zu machen, auch mit Curl. Und das unterstützt sie auch schon. Verstehe ich richtig, oder? Das Streamhandling, ja, wir sind immer noch, also die Frage habe ich am Anfang gar nicht so voll beantwortet. Wo sind wir jetzt gerade? Wir sind tatsächlich noch vor dem V1. Das heißt, wir sind noch tatsächlich dabei, diese Contracts für die Symphony Backwards Compatibility Promise klarzukriegen. Und besonders, wenn es dann darum geht, wie man Reasoning im Stream rauskriegt, zum Beispiel. Also gerade so Thinking Content, das fliegt ja ja zwischendurch mal entgegen, so zwischen den eigentlichen Message und Tool Calls. Und das dann da an der richtigen Stelle rauszuziehen, typisiert am besten noch, damit du wirklich ein Benefit davon hast, ist gar nicht so ohne, wenn man das für OpenAI, Anthropic und Gemini, also möglichst agnostisch haben will. Da sind wir noch dran.

SPEAKER_03 6:57

Mit dem Reasoning sprichst du vielleicht schon eine ganz interessante Fragestellung an. Jetzt ist ja Inference funktioniert ja erstmal überall gleich so. Text rein, Text zurück. Aber es gibt ja in den letzten 12, 18 Monaten immer mehr Entwicklungen, wo sich diese ganzen Anbieter vielleicht doch auch anfangen zu unterscheiden. So, wie machen sie Tool Calling, wie machen sie Reasoning, wie machen sie vielleicht auch File-Uploads, hast du eben schon angesprochen. Da stelle ich mir so ein bisschen die Frage, jetzt hast du gesagt, ihr wollt das alles so vereinheitlichen, aber wie unterschiedlich ist denn dieses Ökosystem überhaupt? Also wie schwer habt ihr das da an der Stelle? Oder gibt es da schon so einen De facto-Standard, der sich quasi durchgesetzt hat?

SPEAKER_01 7:41

Es gibt, glaube ich, da zwei unterschiedliche Ebenen. Also wenn wir jetzt einmal nur die Inference anschauen, dann kann man schon sagen, dass sich, sag ich mal, durch die Completions API, also die Chat-Completions, die OpenAI eingeführt hat, da sind ziemlich viele direkt hinterhergelaufen und haben das ähnlich gemacht, um dann auch mit den SDKs kompatibel zu sein. So, und das nächste Level war dann eigentlich Open Responses. Das ist so diese Responses API, die auch von OpenAI zusammen mit, auch zusammen mit Hugging Face, glaube ich, standardisiert wurde und auch ein bisschen neutraler die Spezifikation gelauncht ist. Das heißt, auf dem Teil geht das schon eigentlich ganz gut klar inzwischen. Da hat sich das ein bisschen konsolidiert über das Ökosystem. Das macht uns das natürlich ein bisschen einfacher. Es ist tatsächlich aber immer noch so, dass dann manche da gerne rausfallen. Ob das jetzt sowas ist wie 11 Labs oder Gemini insgesamt, da gibt es einfach nochmal andere Contracts. Und das versuchen wir tatsächlich dann einfach direkt mit abzubilden. Und ein Layer, der auch noch mit dazukommt, ist sowas wie ein Model Catalog, was wir haben, wo man dann sozusagen wirklich plattformspezifisch oder providerspezifisch das wirklich laden kann. So, und das ist tatsächlich auch noch nicht standardisiert. Und die zweite Ebene, die wir haben an der Stelle, ist das, was dann zum Beispiel OpenAI mit der Assistant API macht, wo man dann auch wirklich Sessions aufmachen kann, Files vorher hochladen kann und dann seine Agents zu bauen. Das ist tatsächlich was, was wir gar nicht bisher machen. Zum einen, weil das sehr vendorspezifisch ist und zum anderen, weil ich das tatsächlich so aus der Brille von Software-Architektur nicht so cool finde, so viel von meiner Business-Logik wegzudelegieren in einen Service. Das heißt, ich würde meinen Agent lieber selber bauen und meine Files lieber selber hosten, als OpenAI zum Beispiel dann oder einen Azure-Indexer zu benutzen zum Beispiel.

SPEAKER_00 9:36

Das wäre jetzt auch irgendwie meine Vorstellung, wie man das bauen müsste, um nicht so ein Vendor-Login zu haben. Was aber auch eigentlich gehen müsste, oder? Dass du sagst, okay, du bist halt eine Library, die dir das anbietet, dass du das irgendwo lokal speicherst und dann irgendwie in einer strukturierierten Weise immer in den Kontext von der AI gibst, oder? Das ist vorstellbar, oder? Voll, voll.

SPEAKER_01 9:59

Es ist nur die Frage, auf welches Produkt du sozusagen setzen willst. Wenn du sagst, okay, ich will die Bedrock Services oder die Azure Assistant oder OpenAI Assistance Feature dafür nehmen. Oder ich will nur die Inference kombinieren mit einem Miley Search oder was auch immer ich selber in der Infrastruktur habe. So und da sind wir, glaube ich, deutlich mehr in dem, okay, ich will selber kombinieren Welt, als dass wir jetzt wirklich nochmal versuchen, so Product APIs über Google, Bedrock und OpenAI zu vereinheitlichen.

SPEAKER_03 10:34

Und wenn wir über selber Kombinieren sprechen, was ist denn alles Scope von dem Library am Ende des Tages? Also wir haben jetzt die ganze Zeit über Inference gesprochen, aber wenn ich jetzt größere Produkte irgendwie erbaue, dann brauche ich da vielleicht auch eine Datenbank, ich brauche eine Vektorsuche, ich muss irgendwie Embeddings erzeugen, so was da alles da reingehört. Wollt ihr das auch alles mit abbilden oder ist das eher so, da gibt es andere Tools für?

SPEAKER_01 11:04

Die Frage ist gar nicht so einfach, weil das ja auch so ein Findungsprozess für uns war, beziehungsweise ist. Jetzt gerade mit Bezug auf die 1.0, die wir möglichst bald mal haben wollen, ist natürlich dann auch so die Frage, was ist eigentlich, du musst nochmal einen Scope wirklich klarziehen. Und ich kann euch jetzt, sag ich mal so, noch ein paar Wochen vor der 1.0 sagen, wo ich jetzt gerade bin, aber würde nicht garantieren, dass es so bleibt. Also meiner Meinung nach ist es so tatsächlich, dass wir die Inference abstrahieren, sowohl HTTP als auch Datenobjekte und da gar nicht uns auf Language Models einschränken. Hugging Face bei der Inference Hub API kannst du alles mit Input, Output, ist es egal, kann Text Classification sein, kann Embedding sein, kann Image Object Detection sein und so weiter. Das haben wir alles so direkt mit drin. Und ich würde aber tatsächlich nicht so weit gehen, zu sagen, wir wollen auch in der Agent-Komponente Memory und Skills und das, was man sozusagen aus anderen agentischen Produkten wirklich kennt als Feature kennt, dass wir das, also wir sind nicht Claude Code oder dein Product-Framework so. Da haben wir jetzt gerade eine Verhandlung, sage ich mal, auch über Maintenance, was an Extension Points ist, okay, was an Feature gehört eigentlich dann in die Produkte. Und das ist tatsächlich, die Extension-Punkte, würde ich sagen, sind immer noch dann Core. Du kannst dich in den Tool-Core-Lifecycle reinhängen, du kannst dich in ein Agent-Input-Output-Plattform-Request-Cycle reinhängen über Events. Aber ob wir jetzt wirklich Chat und Memory und all diese Dinge mitliefern, eher nicht.

SPEAKER_03 12:49

Du willst uns da mal mitnehmen in die Diskussion? Also was waren denn so die Argumente dafür und was waren die Argumente dagegen und was war am Ende ausschlaggebend?

SPEAKER_01 13:01

Gute Argumente dafür sind, dass es tatsächlich auch so ein bisschen Competition ist, wenn du dir anschaust, wie unterschiedliche Agent-Frameworks gerade wachsen, gibt es links und rechts auch ein PHP, gibt es ja inzwischen eine Handvoll mit Lelephant und Laral AI SDK, sitzt auf Prism, glaube ich, und dann haben wir Norean AI. Das ist natürlich alles auch total cool zu sehen, dass so viel los ist. Und dann ist natürlich auch ein gewisser Anreiz dabei, mehr Feature zu haben. Und auf der anderen Seite ist das halt Open Source. Ich bin ja jetzt nicht Vollzeit Symphony AI Developer. Das heißt auch, dass man das nachhaltig macht, ist so ein Aspekt. Und ein ganz spannender Aspekt, den wir jetzt hatten, auch in der Diskussion zuletzt ist, in diesen agentischen Zeiten von Cloud Code, wie viel musst du eigentlich shippen und was ist eigentlich das, womit sich, also willst du jetzt eine Memory-Implementierung schippen auf deine eigenen Extension Points, die du dann wieder konfigurierbar machst? Oder kann jemand mit einem Prompt relativ gut sich in die Extension Points reinhängen und die Memory-Implementierung selber machen, die sie machen, brauchen? So, ich glaube, das ist auch so ein Turning Point, den wir generell nochmal so in Open Source vielleicht sehen, dass Feature-Reichtum an sich vielleicht gar nicht so ausganggebend ist, sondern dass die Extension Points, dass die rock solid sind und eine ermöglichen, Dinge reinzuwerfen in das Ding. So und das ist das, wo ich jetzt gerade bin, dass ich sage, okay, vielleicht ist sowas wie ein Tool Confirmation Strategy Pattern an gar nicht so relevant, wenn ich einfach meine Confirmation Strategy selber reintacker über die Extension Points, die wir haben rund um Tool Calls. So, das ist nochmal so ein Consultant, der einfach neu ist für mich in dieser Welt.

SPEAKER_00 14:44

Da stelle ich mir direkt die Frage, was ist denn, also das ist vielleicht ein bisschen auf eine fundamentalere Ebene, aber wenn die AI das so viel, also so gut selber machen kann, dann könnte man so argumentieren, dass die Library nicht mal sinnvoll ist oder siehst du diese Basisfunktion immer noch als sehr, sehr wertvoll oder essentiell, wenn du dieses Argument noch ketzel als ich?

SPEAKER_01 15:07

Nee, finde ich gut, finde ich gut, weil das sind genau die Fragen, die natürlich, das beschäftigt uns alle. Brauchst du zukünftig noch diese ganzen 1500 NPM-Dependencies oder kannst du das einfach machen selber? Ich glaube, mein Argument an der Stelle wäre, du willst in deiner Codebase bestimmte Concerns lösen, bestimmte nicht. Manche willst du kognitiv selber managen und manche nicht. Wenn du jetzt sagst, okay, ich habe ein Memory, ich baue ein Produkt, das hat ein Agent-Memory, dann hast du klare Requirements dazu. Das heißt, da gehört dann die kognitive Last meiner Meinung nach zu dir. So, aber der Extension-Punkt, wie du dich dann damit reinhängst in den Agent. Du sagst, ich will, also ein Agent, die langweiligste, also meine Erklärung für ein Agent, das ist glaube ich die langweiligste, die du haben kannst, ist ein Iterator über LLMs und Toolcalls. Mehr ist es nicht. Erst durch das, was im State passiert, den Kontext, wird es halt irgendwie cool. Und ich glaube, das kannst du, das willst du nicht selber lösen. Klar könntest du jetzt sagen, ich will jetzt die Streamhandling, aber bis du das zurechtgepromptet hast, das kann ein bisschen dauern.

SPEAKER_00 16:13

Okay, das ist ja so ein bisschen die Basis des Arguments: Okay, du bist am Ende immer noch verantwortlich dafür, was der Agent dir ausspuckt und ob das dann auch funktioniert. Und klar, der Kram, der einfach funktionieren soll, ist wahrscheinlich sinnvoll, den auch zu lagern, sich dann auch nicht Gedanken darüber machen zu müssen, funktioniert das? Oder worauf muss man da achten oder so? Ja. Ja, ist valide.

SPEAKER_03 16:38

Du hast gesagt, ihr seid gerade auf dem Weg zur 1.0 und vielleicht bis die Folge draußen ist, ich habe es gerade gar nicht auf dem Kalender. Vielleicht ist dann schon die 1.0 draußen. Oh, stimmt. Wann ist das online? Das kann ich gleich nochmal unauffällig nachschauen, während du die nächste Folge war und wartest. Weil ich mir auch Gedanken darauf gemacht habe, wie man so einen QA-Prozess in so einem Library halt abbilden kann. Weil natürlich willst du auch ein bisschen testen und so, aber das ist ja alles so sehr nicht deterministisch, was da passiert. Und wir selbst haben, also ich weiß nicht, gerade sprich für dich, aber ich habe jetzt noch kein großes AI-Projekt gebaut und schon gar keins mit Tests. Ich frage mich, wie macht man das denn? Also, jetzt hast du irgendwie hier deine ganzen Adapter und Abstraktionsschichten und sowas und dann willst du es mal testen. Wie? Vielleicht, also angefangen davon bei, das Ganze ist nicht deterministisch, wie kann man überhaupt irgendwie festlegen, was eine saubere Response ist und was irgendwie Murks ist, hin zu der ganz banalen Frage, so ihr als Open Source-Projekt, die jetzt mit irgendwie 20 verschiedenen APIs spricht, wer bezahlt denn das? Weil Tokens kosten ja auch Geld am Ende des Tages.

SPEAKER_01 17:52

Aber so banal ist die Antwort auch, ne? Es geht halt mit einer Kreditkarte. Also tatsächlich ist es so, dass ich, ich habe einen AND-File rumliegen mit 50 verschiedenen Secrets und Token. Und hab, wir haben, also tatsächlich ist es ein Requirement, wenn du eine neue Bridge bei uns reinbringst, ob das jetzt für einen Vektorstore ist, dann erwartest du das Docker Compose Setup. Und wenn du einen neuen Provider reinbringst, und auch wenn das der ist, der vom französischen Government, dann geht es darum, dass am Schluss da ein Example liegt, was ausführbar ist und ich dann auch irgendwie ein API-Token dafür kriege. Das heißt, ich habe einen Runner, der bei mir lokal und mit meinem Skill halt parallelisiert diese 260 Examples, die wir inzwischen für die unterschiedlichen Vector Stores und Streaming mit Anthropic und Streaming mit Tool Call bei OpenAI und 11 Labs hier und alles ausführt. Also im Moment ist das ein sehr naiver, aber der beste Approach, den ich habe.

SPEAKER_00 18:57

Boah, also das interessiert mich jetzt voll, also was sind das für 260? Ich dachte, du wolltest jetzt ans N-File ran oder so. Die könntest du immer schicken. Also vor allen Dingen Vektor Stores, also wie was machen die in der Library?

SPEAKER_01 19:16

Wir haben tatsächlich in der Store-Komponente, da haben wir quasi so eine Indexing-Pipeline. Das heißt, es geht los mit, da liegen irgendwelche Markdown-Files oder in Memory. Und die werden dann, gibt es eine Transformerschicht, wo du dann sagen kannst, okay, ich will es chunken. Und dann gibt es nochmal einen Vectorizer, der dann ganz klassisch aus den Dokumenten die Embeddings macht und dann geht es in den Store. Das ist unsere Indexing-Pipeline. Und für die Vector-Stores haben wir dann tatsächlich einmal Integration-Tests, die wirklich auf dem Docker gebooteten Image arbeiten, wenn wir es dann haben. Ansonsten bei Pinecone ist es. Nee, Pinecone gibt es inzwischen liebst ein Mock-Image. Und für diese Rack-Indexing-Pipeline haben wir tatsächlich dann auch Examples, die von Markdown-File bis hin zum Query am Schluss das einmal durchtackern. Das ist ein bisschen aufwendig, aber mein Selling-Point an der Stelle ist halt auch, wenn du jetzt sagst, ich möchte mit Symphony.ai und Pinecone und Markdown-Files einmal Rack sehen, gehst du in das Example und kannst von oben bis unten durchschauen.

SPEAKER_03 20:22

Diese ganzen Examples und Testcases, nur um den ersten Teil der Frage nochmal aufzumachen, wie testet ihr das denn am Ende? Weil wie gesagt, der Output ist ja nicht deterministisch. Und wie sieht so ein CI-Durchlauf bei euch am Ende aus, bis wirklich alle Tests auf grün sind und gesagt wird, ja, das ist okay, was da zurückkommt.

SPEAKER_01 20:42

Also für die GitHub CI haben wir tatsächlich einfach eine relativ kranke Matrix, die aber nicht an meiner Kreditkarte hängt. So, das geht leider nicht. Aber wenn du in so einen Pull Request reinschaust, dann siehst du am Schluss sind da 400 Checks durchgelaufen für ein Change. Also in diese so hart wird das multipliziert, weil es einfach sehr viele Integration Bridges sind. Und da haben wir Integration Tests auch mit Docker, was wir drinnen nicht haben, außer es gibt für OpenAI einen manuellen Trigger, um wirklich auch API-basierte Tests zu machen. Das behalten wir uns aber vor, dass wir das nicht auf vier Pull-Quests machen. Und ansonsten ist das tatsächlich noch ein ungelöstes Problem, was ich manuell mit so einem, ich habe so einen Example-Planer, der mir das parallelisiert. Aber das mache ich dann vor einem Release, gucke ich rein und gucke, ist das jetzt eine ungewöhnlich hohe Zahl an Exit-Codes, die nicht 0 sind. Aber ansonsten schaue ich das einmal durch. Ich kriege einen Katalog und schaue es durch. Das heißt, wir haben da noch nichts, geil, wäre nochmal so eine Ewald-Schicht, aber die Komponente haben wir für die 1-0 rausgescopt.

SPEAKER_03 21:47

Aber das heißt, Evals sind auch was, was ihr euch für das Library anguckt?

SPEAKER_01 21:51

Oh, ich hätte Bock drauf, ja. Tatsächlich, weil es einfach, also bei den Sachen, die bisher, die wir jetzt bei der Arbeit gebaut haben oder ansonsten. Man braucht es ohne jeweils, also hat Max ja auch neulich erzählt, in der Folge. Also ohne geht es eigentlich nicht. Kommt auch bei Skype in der Folge zu.

SPEAKER_00 22:11

Zu Eweils?

SPEAKER_01 22:12

Ja. Cool.

SPEAKER_03 22:13

Ist schon cool in Planung. Ich habe übrigens gerade geguckt, die Folge hier wird, je nachdem, wie die Folgen davor sich so verhalten, sagen wir mal Ende Mai, Anfang Juni veröffentlicht. Schafft ihr das?

SPEAKER_01 22:26

Da sind wir ja hoffentlich, ja. Das ist immer schwierig, aber ich würde sagen, wir sind dann schon durch mit der 1-0 her. So, ihr habt jetzt gehört. Haben wir gut gemacht.

SPEAKER_03 22:36

Ganz kurz auf Pause drücken beim Podcast-Player und einmal auf AI.symphony ist das, glaube ich, ne?

SPEAKER_01 22:42

Ja, AI.symphony.com, ja.

SPEAKER_03 22:44

Einmal nachschauen, das Pressure kommt. 1.000. Oh, für uns jetzt natürlich auch der Pressure, ne? Wenn jetzt die Folge aus irgendeinem Grund irgendwie so Ende Juni erst erscheint, dann schreiben uns die Leute so, ah, die habt ihr nur geschoben, damit der Christopher noch Zeit hat und die 1-0 fällt. Können wir so machen, können wir so machen. Wir timen das zusammen, das können wir schon hin. Das ist ja auch schön, wenn die Hörerin sich das direkt beanschauen kann. Also unabhängig davon, dass das jetzt bei euch alles in PHP gebaut ist, worüber wir noch gar nicht gesprochen haben, ob das irgendwie eine gute oder eine schlechte Entscheidung ist, finde ich es auf alle Fälle cool, dass ihr für die ganze Architektur, wie du gerade gesagt hast, diese Beispiele halt mitliefert. Weil unabhängig von der Sprache, das alles mal in Action zu sehen und zu schauen, wie diese ganzen Teile irgendwie zusammengehören und was man da braucht, das ist, glaube ich, das, was vielen mit am allermeisten hilft, gerade beim Einstieg. Von daher voll nice. Das ist so passiert. In AI-Zeiten sehr langer Zeit, in menschlicher Zeit wahrscheinlich noch gar nicht so lange her, war ja Langchain irgendwie das Framework, was man so genommen hat für AI-Use Cases. Und das hat meiner Meinung nach immer so ein bisschen daran gelitten, dass es sehr, eine sehr hochgradige Abstraktion war und man sehr viel schreiben musste, um überhaupt erstmal irgendwas damit zu machen. Also jeder, der mal so ein Langchain-Projekt irgendwie aufgesetzt hat, Gareth hat zumindest genickt, hast du wahrscheinlich auch mal angeguckt. Der wird ja gesehen haben, okay, also bis da wirklich mal was an Inference passiert oder so ein Embedding erzeugt ist oder so, da hast du sehr viele Module zusammengeschraubt irgendwie. Und deswegen auch so meine Frage an dich, Christopher, so wie findet ihr so das richtige Level an Abstraktion, um zu sagen, okay, damit machen wir es einfacher für die Leute zu benutzen, aber noch nicht zu kompliziert, um auch die einfachen, in Anführungszeichen, Einstiegs-Use Cases nicht unattraktiv zu machen. Weil ich glaube, das ist ja schon das, wie die meisten Leute irgendwie dazu kommen. Die allerwenigsten Leute, vermute ich mal, kannst du auch gerne gleich das Gegenteil erzählen, aber die allerwenigsten Leute kommen ja an wahrscheinlich und sagen so, oh, ich habe hier schon meine Vektordatenbank und hier habe ich irgendwie mein kleines Model, um die Embeddings zu erzeugen. Das Einzige, was ich brauche, ist eine Client-Library. Dann wäre alles perfekt und ich könnte sofort loslegen. Meistens ist es ja so, ich will irgendwie erstmal ein Proof of Concept bauen und dann wächst dieses Projekt irgendwie so organisch raus. Und deshalb glaube ich, ist es halt wichtig, dass diese Einstiegs-Use Cases auch gut abgebildet werden können und man nicht erst 50 Seiten Dokumentation lesen muss, um irgendwie das erste Prompt da loszuschicken. Wie versucht ihr die Hürde da gering zu halten?

SPEAKER_01 25:32

Das ist eine ziemlich gute Frage und die ist tatsächlich für mich relativ schwer, weil ich da jetzt irgendwie seit zwei Jahren drauf schaue, auf die Codebase. Das ist sehr schwer zu reflektieren. Ich glaube, das, was mir am Anfang gut geholfen hat, waren gerade diese Examples. Wir haben auch nochmal eine Demo-App im Repository Map, womit man halt dann einfach inzwischen sehr langweilig, diese ganzen Chat-Demos, aber da sind großteils Chat-Demos drin und auch ein bisschen was zu Structured Output oder Image Object Detection. Aber ich glaube, das ist das am ehesten, wo ich sagen würde, das ist so mein Navigator an der Stelle, dass ich auf diese Examples drauf gucke und dann nochmal Gegenchallenge. Ist das eigentlich die API, die ich haben will? Und tatsächlich ist das noch eines der Items, was wir, was Oskar und ich jetzt letzten Freitag auch nochmal besprochen haben, dass uns das mit dem Agent-Interface so noch nicht ganz passt. Weil tatsächlich gibt es ja auch einfach so ein bisschen Erosion über jetzt zwei Jahre, wo man dann merkt, gut, am Anfang war das vielleicht wichtig und richtig so, aber inzwischen gibt es vielleicht sowas wie die Instructions sind ja beim Agent was sehr, sehr Hochwertiges vom Contract her. Und bisher war das dann immer so, dass man das als erste System-Message in die Message Bag vom Context gepackt hat. Und eigentlich würde ich gern differenzieren, auch in unserem Interface. Das heißt, ich würde sagen, es ist ein wiederkehrendes Reflektieren auf diesen Examples und Beispielcode, was mir zumindest hilft. Und das andere ist, wir haben, ich habe jetzt ein paar Workshops gegeben, auch bei der SymphonyCon oder Symphony Online, wo ich dann wirklich direkt mit Leuten zusammen die Übungen mache und dann auch sehe, quasi, was irritiert die Leute, was hilft ihnen. Und ich glaube, das ist ein bisschen das, was ich hoffe. Aber es ist schwer zu objektivieren dann, glaube ich.

SPEAKER_03 27:23

Das, was du gerade angesprochen hast, man schaut da sehr lange drauf und dann gibt es vielleicht so ein paar Sachen, die man wieder anders machen würde. Da baut vielleicht mein nächster Punkt so ein bisschen drauf auf. Diese ganze AI-Welt dreht sich ja unglaublich schnell. Fast so schnell wie das JavaScript-Framework-Ekosystem. Ich weiß nicht, was schneller entsteht. Neue Modelle oder neue JavaScript-Frameworks, aber so ungefähr ist so die Möglichkeit.

SPEAKER_01 27:53

Die Agent-Protokolle ist ja irgendwie, ich weiß nicht, wie viel gibt es inzwischen.

SPEAKER_03 27:57

Ja. Und wie fühlt sich das dann für euch so als Maintainer an? Das ist ja so ein Katze-und-Maus-Spiel eigentlich. Weil es kommt ein neues Agent-Protokoll raus oder ein ganz neuer irgendwie architektonischer Ansatz. Jetzt gibt es irgendwie, weiß nicht, MCP ist auch schon ein bisschen älter, ja, aber das ist ja auch irgendwann mal noch dazugekommen und das muss auch irgendwie unterstützt werden und dann die Agent-Protokolle und Agent-to-Agent und dann ruft vielleicht dein Agent irgendwie Sub-Agents auf und so weiter und so fort. Und ich weiß nicht, also wenn du morgens so den Rechner aufmachst, wie viel Angst ist da so dabei, dass irgendwas Neues jetzt irgendwie gerade rausgekommen ist, das ihr jetzt auch noch unterstützen müsst? Oder ist das überhaupt gar kein Problem für euch, weil ihr sagt, naja, Scope ist fertig, Feature Set ist final und alles andere machen wir jetzt erstmal nicht?

SPEAKER_01 28:42

Nee, das müsste sich jetzt, glaube ich, so auf zwei Ebenen, weil es ist für mich auch das erste Mal, dass ich so ein großes Open Source Projekt Maintainer. So, das heißt, automatisch ist es so, dass du also für mich relativ viel am Strugglen bist und dann diese Notification-Bubble auf GitHub allein, das ist ja schon was, was halt stressen kann. Und dann hast du noch die Leute, die halt anderer Meinung sind und da muss man ja auch immer überlegen, ob die jetzt recht haben oder ich selber. Und dann kommen natürlich noch diese fünf Newsletter dazu, die man abonniert hat und dann die im E-Mail-Postfach landen und dann einem erzählen, was da jetzt alles macht. Das ist schon real. Also das spüre ich, sag ich mal. Aber ich habe auch gemerkt, dass so eine gewisse Trägheit schon auch hilft. Ich habe so eine gewisse Trägheit entwickelt, nicht bei allem jetzt immer direkt zu denken, okay, wie bauen wir das jetzt ein, sondern erstmal abzuwarten, ob es dann irgendwie nach zwei, vier Wochen auch noch irgendwie dann wieder ein Issue ist dazu. Weil, ich sag mal so, Sub-Agents, als das ein Baseball wurde, haben wir das gelöst, indem wir Agent as a Tool einfach umbenannt haben. Also das war schon vorher da, aber war halt einfach konzeptionell, und ich würde sagen, tatsächlich, konzeptionell haben wir sehr viel von dem Teil, ist wirklich so Abstraktionspattern und Serialisierungspattern. Und dann die zwei Ideen, auf der die Plattform steht, ist halt einfach Tool Calling und Structured Output. Da ist nicht viel passiert in den letzten zwei Jahren. So doof das klingt. Und ich glaube, der Rest ist sehr viel, ich würde gerne mehr Richtung Gen UI gehen. Das ist tatsächlich was, was ich noch nicht so geknackt habe, wie wir das angehen. Das ist so ein Buzzword, was auf jeden Fall noch, ob das jetzt A2I, ATUI oder was, das weiß ich nicht. So, aber oder MCP-Apps. Aber das ist, glaube ich, so das nächste, was ich mir langfristig anschauen will. Ich versuche es jetzt wirklich zu filtern.

SPEAKER_03 30:35

Das ist so das Problem aus deiner Perspektive, ne? Oder aus eurer Maintainer-Perspektive. Dasselbe gibt es ja aber auch aus Developer-Schrich-Library-Anwender-Perspektive. Wenn ich mir jetzt das Library angucke, muss ich ja für mich auch so eine Abwägung treffen und sage so, okay, will ich quasi das Library nutzen und damit so gefühlt den Trade-Off eingehen, dass ich vielleicht einen halben Schritt hinterher bin und jetzt nicht Gen UI gleich nutzen kann oder warten muss, bis Subagents unterstützt, Strich-Strich, umbenannt wurden. Sowas, ja. Wie nehmt ihr das wahr, auf wie viel Gegenliebe oder Akzeptanz stößt da so ein Library oder wie viel Angst haben die Leute, dass sie vielleicht irgendwas verpassen könnten, wenn sie auf so eine Abstraktion schlicht setzen?

SPEAKER_01 31:25

Ich glaube, dass, also wir haben ein paar Learnings da schon durch. Am Anfang war das so, dass wir zum Beispiel, klingt jetzt im Nachhinein total banal, so, wir haben die Model-Namen. Wir haben gedacht, das ist cool, wenn ich einfach eine Konstante habe für GPT-4. So, dann kann ich das direkt mit Autocompletion, habe ich es da und kann es nutzen. Ist aber so vom Change-Szenarien. Ich will ja nicht meine Library updaten, nur weil da ein neues Model released wurde. Das ist ganz klar so ein Fehler gewesen. Und generell haben wir an vielen Stellen durch Decoration, Pattern und Interfaces die Möglichkeit, du kannst dich relativ viel raufsetzen auf Sachen, die wir gebaut haben, ob es jetzt die Toolbox ist, ob es der Serialization Contract ist, den wir haben. Das heißt, ich würde das erstmal ganz defensiv beantworten mit den Extension Points, die wir haben. Und das Einzige, was wir da tatsächlich noch wirklich als Schmerzpunkt haben, ist Streaming. Also Streaming funktioniert, aber es ist tatsächlich dich in, also diesen Generator, den wir da gebaut haben, der halt sozusagen aus dem HTTP-Layer bis in den DTO-Layer die einzelnen Deltas hochhieldet, dich da irgendwie entspannt reinzuhängen für deinen eigenen Extension Point, das noch ein bisschen, muss man schon genau wollen, sag ich mal.

SPEAKER_03 32:47

Und um ganz kurz bei den Developern zu bleiben, was glaubst du, oder weißt du vielleicht sogar, ist der größte Selling Point für das Library am Ende des Tages? Ist es so dieses, boah, ich bekomme halt viel Abstraktionen, Interfaces und DTOs irgendwie aus einer Hand und muss mir um das alles irgendwie nicht mehr Gedanken machen, sondern kann direkt anfangen, was zu bauen und das zu nutzen? Oder ist es eher dieser Punkt, wenn ich darauf aufbaue, ist es relativ einfach für mich am Ende von, weiß nicht, JetGPT oder GPT-5 auf Gemini, auf X-beliebiges anderes Model zu wechseln, weil da hätte ich auch noch eine kritische Frage zu. Aber erstmal, vielleicht so, warum kommen die Leute überhaupt?

SPEAKER_01 33:31

Ich glaube, das eine ist so ein bisschen der Stack an sich, weil du kannst relativ easy, wenn du in eine PHP-App schon hast, jetzt dieses Feature, also diese Feature-Welt aufmachen. Und das ist gerade, wenn es um Tool-Calling geht, ist das schon ziemlich verlockend, einfach zu sagen, okay, ich habe einen Agent, der kann jetzt in meinem Service-Kontext einfach zugreifen. So, und das heißt, wenn du Bestandsanwendungen hast, auch gerade mal größere, ist das einfach, glaube ich, ganz gut. Ich würde tatsächlich, und so habe ich die Workshop auch meistens angefangen, einfach mit dem HTTP-Client anfangen, um Dinge zu verstehen. Das heißt, einfach nur direkt die Library installieren und dann irgendwie Agent macht schon irgendwelche Dinge. Das würde ich gar nicht empfehlen als Start. Ich würde schon sagen, die HTTP-APIs mal auszuprobieren vorher. Muss nicht Current sein, aber irgendwie so ein HTTP-Client oder Gasle, das ist, glaube ich, fürs Verständnis ganz cool. Ansonsten würde ich sagen, ist der größte Selling Point tatsächlich, dass du dich nicht um so Grundlagendinge kümmern musst.

SPEAKER_03 34:39

Weil was ist, also was ich immer so ein bisschen hinterfrage bei diesem ganzen, na, es gibt ja einen Adapter und du kannst irgendwie alle anderen Modelle damit ansprechen. Wir haben das ja schon auf verschiedensten Seiten gesehen. Es gibt Clients, die das lösen, so wie ihr, aber es gibt ja auch APIs, die quasi dasselbe Versprechen mitbringen, die halt das serverseitig sozusagen implementieren und sagen, wir bieten dir einen Endpunkt an und du kannst dann quasi aussuchen, ob wir das intern weiterleiten, weiterrouten an OpenAI, Entropic, Gemini, was auch immer.

SPEAKER_00 35:08

Sowas wie Open Router. So was wie Open Router.

SPEAKER_03 35:12

Und ich frage mich halt, wie real dieses Versprechen wirklich ist, weil wenn ich mir jetzt vorstelle, ich baue eine Anwendung und ich teste und entwickle die jetzt gegen, sagen wir, GPT-5. So, ja, jetzt bin ich irgendwie unzufrieden, weil die Leistung nicht mehr stimmt, der Preis nicht mehr stimmt, das Modell wird abgeschaltet, keine Ahnung, ich muss jetzt wechseln. Dann kann ich ja gefühlt meine halbe Business-Logik mit rauswerfen, weil ich muss ja das ganze Prompt, also gefühlt muss ich ja viel von dem Prompt neu schreiben. Alles, was ich feingeführt habe, alles, was ich getestet habe, ein anderes Modell verhält sich ja komplett anders. Und ich frage mich, in dem Moment, wo halt viel von dieser Business-Logik so nicht deterministisch wird, wie praktikabel es überhaupt ist, mein halbes LLM unten drunter auszutauschen. Das kommt bestimmt auf den Use Case an. Wenn ich unser Translation-Tool hier anschaue, was Benni bei uns intern gebaut hat, um die ganzen Spiele zu übersetzen und sowas, das wäre, glaube ich, machbar mit vielen anderen Modellen auch. Ich glaube, sie haben es ja auch mit verschiedenen Modellen getestet. Wenn ich mir jetzt aber sowas überlege wie unser Buchhaltungssystem des Bandis, was wir da nutzen, was ja so deine Rechnungen durchscannt, ne? Und dir dann so findet, hey, was ist dein Steuerbetrag, was ist dein Rechnungsbetrag, wer ist dein Rechnungssteller, bla und füllt das irgendwie alles für dich aus. Boah, da weiß ich nicht, ob man da einfach so das LLM unten drunter austauschen könnte und der noch genauso passende Ergebnisse liefern.

SPEAKER_00 36:32

Ich weiß auch gar nicht, ob das wirklich das Szenario ist, was ich mir vorstelle, weil ich habe das Gefühl, so wenn du eine Business-Logik gefunden hast, die funktioniert, dann willst du auf gar keinen Fall das Model wechseln. Aber in der Entwicklung willst du bestimmt häufiger mal gucken, so, okay, welches Model klappt denn vielleicht? Und dafür würde ich die Abstraktionsebene auf jeden Fall haben. Schwieriges Wort. Ja, eben schon. Für mich zumindest. Macht's auch einfach. Und selbst, weißt du, selbst wenn du dann mal wirklich den Moment hast, wo die API Tore geworden ist, dann kannst du halt relativ einfach wieder gucken, okay, welches Model klappt denn trotzdem noch gut mit dem, was ich habe.

SPEAKER_03 37:13

Also ich glaube, du hast natürlich recht, ich glaube, wirklich, wollen tut man das Model nie wirklich tauschen. Aber wir haben das jetzt ja schon in den letzten paar Jahren gesehen, die werden halt auch deprecated und abgeschaltet irgendwann. Voll. Und manchmal tatsächlich auch relativ schnell. Ist ja auch so ein Punkt.

SPEAKER_01 37:29

Ich glaube, der wichtige Teil ist einfach, dass man die Möglichkeit erstmal hat, das so zu bauen, dass man an einer zentralen Stelle das, also und selbst wenn du es da noch hardcodest, das muss ja nicht mal unbedingt dann irgendwie in der Konfiguration sein. Aber was ich tatsächlich jetzt auch gerade von dem, von der Produkt-Welt, in der ich so unterwegs bin, ganz spannend finde als Idee, ist halt auch wirklich dann Prompts und Settings dazu, Endnutzern zur Verfügung zu stellen und nicht nur, also ihr habt das vielleicht auch schon bei manchen Kunden oder bei manchen Endnutzern, dass die auch eine gewisse Awareness haben für Models. So dass die sagen, ja, ich habe jetzt das Opus benutzt. Und manchmal entsteht so ein Consumer Mastery-Feeling dabei, weil ich habe jetzt mal das ausprobiert, ich habe mal das ausprobiert. Und wenn du halt eine Anwendung baust, wo du dann in den Administrationssettings auch nochmal switchen kannst zwischen unterschiedlichen Dingen. Und der Anwendungscode ist davon halt einfach ein bisschen entkoppelt. Und du kannst vielleicht sogar auch Ponds zur Verfügung stellen, dann ist das eine Infrastruktur, die sozusagen Symphony. Die dir einfach bietet direkt.

SPEAKER_03 38:34

Ja, das ist wahrscheinlich ein cooles Argument, gerade auch in diesen ganzen Bring-Your-Own-Key-Szenarien oder sowas, wo du halt sagen kannst, meine Anwendung erfordert halt ein LM, du kannst ein Key mitbringen von Tropic, Gemini, OpenAI, whatever, und wir nutzen dann halt einfach was, was möglich ist sozusagen. Ja, da habe ich nicht drüber nachgeladen, ja.

SPEAKER_01 38:55

Ja, die Alternative ist, wir wollen ja bei Symphony, also wir wollen das Symphony AI auch so bauen, dass wir uns nicht auf irgendeinen Provider einlocken. Das heißt, wir haben, wenn wir sagen, wir wollen in Symphony irgendwelche I-Features schippen, haben wir gar keine andere Wahl. Wir wollen ja nicht Symphony AI powered by OpenAI bauen. Das ist halt, geht halt nicht.

SPEAKER_00 39:16

Feel ich auch nicht. Sind lokale Modelle ein Thema bei euch? Also die auch in der Web-Runtime laufen?

SPEAKER_01 39:26

Also in der Client-Runtime des Browsers. Ja, ja, genau. Ich würde gerne, ich weiß nur noch nicht genau, wie. Also ich fände es tatsächlich geil, irgendwie da sich quer durchs Auge quasi da die Inference aus dem Browser rauszuholen. Aber ich, ehrlich gesagt, selbst wenn wir das irgendwie zusammenbauen, glaube ich nicht, dass das ein cooler Use Case ist für eine Server-Side-Language. Also was wir halt zur Verfügung stellen, ist Olama Bridge, LM Studio, Docker Model Runner, diese Klassiker. Und das, was so ein bisschen, da kommen wir vielleicht nochmal zu diesem PHP-Punkt, was wir jetzt auch als eine Bridge haben, ist eine Transformers PHP, wo dann die Inference gar nicht über HTTP passiert, sondern über sozusagen eine FFI-Bridge in den C-Bereich. Und dann kannst du wirklich in der PHP-Runtime auch Model Inference machen.

SPEAKER_03 40:26

Das kannte ich gar nicht. Was wird da angesprochen am Ende in C? Ist das dann so Lama C oder was?

SPEAKER_01 40:31

Also OneNix. Ah ja. So, das ist von Kieran eine ziemlich abgefahrene Library, die durch dieses Foreign Function Interface C-Binings aufbaut. Frag mich nicht genau, wie das funktioniert. Schade.

SPEAKER_03 40:48

Also ich finde es cool, dass sowas geht. Ich frage mich, ob das sinnvoll ist. Weil es erfordert ja quasi Co-Location, oder? Weil in dem Moment, wo ich das quasi in C Lokal ausführen will, muss es ja auf meiner Maschine laufen. Und mit Network Requests, so overheads die natürlich sind, aber habe ich halt den Vorteil, dass es entkoppeln kann. Also wenn jetzt meine Anwendung irgendwo in meinem Kubernetes-Cluster läuft oder so, dann will ich schrägstrich, kann ich oder muss ich ja gar nicht garantieren können, dass auf demselben Knoten irgendwie jetzt auch mein LLM irgendwie läuft, weil die Maschine, die das ausführt, dafür vielleicht auch gar nicht in der Lage ist.

SPEAKER_01 41:27

Ich finde es nicht so gut.

SPEAKER_03 41:28

Das sieht ja so ein bisschen aus.

SPEAKER_01 41:30

Also du ist auf jeden Fall ein total valider Punkt. Das macht es echt schwieriger. Vor allen Dingen, ich würde auch gar nicht in dieses Game reinholen, Inference zu scalen. Das wäre mir viel zu viel zu krass. Aber ich würde nochmal als ein Argument, was ich hätte, wäre, dass ich sowieso versuche, wenn es geht, die Abhängigkeit in irgendeinen asynchronen Prozess zu verlagern, dass es in einem Worker ist. Und dann könntest du auch überlegen, ob du da einen PHP-Worker hast, der halt auf irgendeiner Maschine läuft, die halt sowas eben im Zweifel könnte. Trotzdem tatsächlich nichts, was ich bisher nach Production gebracht habe und das sehe ich auch gerade nicht in meiner nahen Zukunft.

SPEAKER_03 42:10

Aber du sprichst einen guten Punkt an mit der Langläufigkeit. Das ist jetzt auch keine klassische Stärke von PHP. Um es mal neutral zu formulieren.

SPEAKER_01 42:22

Bezogen auf Part TP oder bezogen auf CLI-Prozesse generell?

SPEAKER_03 42:27

Genau, nein, CLI-Prozesse generell, weil du gerade den Worker ansprachst, der das dann vielleicht abarbeiten muss auf dem Node. Und ich weiß, dass es da mittlerweile viel Bewegung in dem Space gibt, aber ich glaube, viele von unseren Zuhörern wissen es so nicht, deswegen lass uns da vielleicht einmal kurz rüber sprechen. Wie problematisch ist es denn aktuell, überhaupt noch so PHP langläufig zu betreiben? Und was muss so euer Library dafür noch explizit tun, um das halt besser zu unterstützen? Ich weiß nicht, sind Memory Leaks ein Problem? Ja, ich meine, irgendwo auf der Webseite habe ich gelesen, so Symphony AI will so das Doktrin von Doktrin für LLMs werden, so ungefähr, ja. Doktrin so als Datenbankabstraktionen früher, weil ich gerade mich schon fragend anguckt. Und Doctrin war ja auch dafür bekannt, irgendwie Memory zu leaken links und rechts. Deswegen so meine Frage, wie viel Sorge muss mir noch um Langläufigkeit machen?

SPEAKER_01 43:21

Also prinzipiell ist das auch in meiner Erfahrung so, dass je länger ein PHP-Prozess läuft, desto ineffizienter wird er. Ich weiß auch nicht, ob ich das jetzt noch eingespeichert habe von vor zehn Jahren. Aber das, was du beim Symphony Messenger hast, und das ist die Komponente, die ich einsetze dann für Asynchron, ich kann direkt mitgeben, wie lange die vielen Messages verarbeitet werden, bis der Prozess durchgestattet wird. Das heißt, du hast immer eine Voll-mäßig, glaube ich, in der Dokumentation gibt es ein Beispiel dann für Supervisor D und das Ding killt sich einfach selber nach zehn Messages, nach einer Stunde, nach zehn Minuten, wie du es konfigurierst. Das heißt, letztlich wäre das dann Ganz elegant Richtung Developer-Land shiftet, das Problem, dass du herausfinden musst, was dein gebautes, dein gebauter Worker sozusagen verträgt. Ich habe tatsächlich, mir ist jetzt gerade überhaupt nicht bewusst, ob wir irgendwelche Memory-Leaks in Workern haben oder sowas, wenn man das länger läuft, ist mir, glaube ich, tatsächlich nicht, ehrlich gesagt, dass wir das Problem haben im Moment. Und der Vorteil im Symphony Messenger ist halt tatsächlich auch, dass du ganz explizit über so ein Resettable-Interface heißt es, quasi zwischen den Messages Dinge freigeben kannst. Wenn du sauber brauchst. Das heißt, das ist auch wieder geschäfte das Problem.

SPEAKER_03 44:39

Wobei man wahrscheinlich ja auch sagen muss, die Langläufigkeit im Umgang mit AI besteht ja wahrscheinlich zu einem sehr großen Teil einfach aus Warten auf das LLM. Es ist ja nicht so, dass da so viel Heavy Lifting gemacht wird, wie wenn ihr jetzt, weiß nicht, Video-Transcoding betreiben würdet, da irgendwie am Stück oder sowas, sondern das ist ja viel I.O. wahrscheinlich was passiert einfach, oder?

SPEAKER_01 45:02

Ja. Und ich würde tatsächlich sagen, das ist auch immer noch relativ valider Kritikpunkt, wenn man so auf Parallelisierungen hinaus will. Es gibt definitiv Lösungen, wie wir gerade auch dann mit Revolt oder Fiber oder React PHP Dinge ganz gut parallelisieren können, sodass du auch kein, dass du asynchron arbeiten kannst. Aber dadurch, dass die Sprache selber jetzt nicht Native Async oder Multithreading macht, sind das immer Lösungen, die sozusagen on top sitzen. Es geht, auf jeden Fall. Und ich hoffe, dass dieser RFC für das True Async irgendwann mal durchkommt und die Sprache das dann auch selber kann. Aber das ist jetzt Opinion.

SPEAKER_03 45:45

Das ist okay, dafür sind wir da. Wenn wir hier keine Meinung hätten, könnten wir auch nur Doku vorlesen gegenseitig. Wir sind ja auch an Menschen und Meinungen interessiert, von daher alles gut. Ja, ich gehe gerade so meinen Fragenkatalog hier durch. Gareth, hast du noch eine Frage?

SPEAKER_00 46:06

Ja, ich hatte eine, die so ein bisschen in eine andere Richtung geht, weil es mich eigentlich immer interessiert, wer so die Leute hinter dem Projekt sind, weil du auch am Anfang von wir gesprochen hast. Das ist das royale Wir. Liebst. Ach ja, das wäre so geil. Glaube ich aber nicht. Also, wer hast du, du hast wahrscheinlich diese Library entstehen lassen. Hast du das mit Leuten zusammen gemacht? Woher kommen diese Leute? Woher kennt ihr euch?

SPEAKER_01 46:34

Ich habe tatsächlich angefangen, irgendwann in einem Separatprojekt erstmal LLM Chain hieß es. PHP LLM war so die Orgel dazu angefangen. Und dann relativ bald ist Oscar, Oscar Stark, aus dem Symphony-Core-Team damit raufgesprungen. Und ab da würde ich sagen, ist es ein Wir, also wirklich grammatikalisch und nicht Majestatis. Und dann tatsächlich hatten wir irgendwie plötzlich Leute, die halt wirklich aus Finnland oder wirklich around the globe angefangen haben zu contributen. Dann haben wir gesagt, okay, irgendwie macht das Spaß und macht das Sinn. Und dann haben wir, ich glaube, Oscar saß in einem Flieger mit Fabienne nach einem Hackday oder irgendeinem Symphony Day in den Staaten. Und dann haben die gequatscht und dann haben wir im März letzten Jahres entschlossen, so machen wir doch aus dem PHP LLM, machen wir mal Symphony AI. Ich hätte tatsächlich, oh, ich weiß gar nicht, das wird hier noch aufgezeichnet, aber ich hätte tatsächlich gerne noch ein bisschen gewartet, das da unter dem Branding auch zu publishen. Weil in dem Moment, also du kannst dich ja entscheiden, willst du es partizipativ auf einer offenen Bühne bauen oder willst du irgendwann bei einer Konferenz den Vorhang fallen lassen und sagen, das ist es. Das sind zwei unterschiedliche Ansätze. Und auch, ich glaube, Laravel hat sich so ein bisschen zu dem anderen Ansatz entschieden. Wir haben dann im Juli letzten Jahres gesagt, okay, hey, wir wollen das bauen, das Symphony AI, wer ist mit dabei? Und dann muss ich extra.

SPEAKER_03 48:05

Gerade dafür kann ja das Symphony Branding auch hilfreich sein, weil natürlich da schon so eine größere Bubble irgendwie mitkommt, anstatt wenn, also nichts gegen dich, ja, aber es macht wahrscheinlich einen Unterschied, wenn du dich irgendwie ins Internet stellst und ein bisschen trommelst und sagst so, hey Leute, lasst das irgendwie alle machen. Oder wenn Fabienne auf der großen Symphony-Bühne steht und sagt so, ihr habt alle Bock auf, wer dann helft ihr jetzt dem Christopher, go.

SPEAKER_01 48:28

Genau, aber das war genau so. Also dass dann auch, als das Monorepo dann aufgebaut war, dass es dann auch okay, dann lass uns möglichst schnell public machen. Und es ist auch egal, wenn da jetzt erstmal kein Tag dran ist, sondern einfach nur, dass Leute Bescheid wissen und die Bock drauf haben können mitmachen. Und jetzt sind wir, glaube ich, bei über 120 Contributern oder sagen wir über 100. Knapp an den 2000 Pull-Requests.

SPEAKER_00 48:52

Das heißt ordentlich Lärm. Und glaubst du, die V1 ist jetzt besser geworden, dadurch, dass ihr das so open, also offen gemacht habt mit der Community zusammen? Oder glaubst du, ihr wärt ähnlich dabei rausgekommen, hättet ihr das so zu dritt, zu zweit, zu dritt gemacht?

SPEAKER_01 49:09

Gute Frage. Ich glaube tatsächlich, dass die V1 wäre früher da gewesen.

SPEAKER_02 49:17

Weil es ja keine Antwort auf die Qualität war, was ja nur eine Antwort auf den Prozess war.

SPEAKER_01 49:21

Ja, genau. Ich glaube, unterm Strich ist es jetzt besser, weil es einen gewissen Findungsprozess dabei hat. Ich glaube auch tatsächlich, dass wir jetzt in den letzten Wochen schon wieder was weggeschmissen haben, also bald jetzt und wieder so ein bisschen mehr auf den Fokus kommen. Aber es ist halt ein Lernprozess dann vielleicht auch als Community dann. Und ich glaube, das ist gerade für PHP in diesem AI-Game schon wichtig, dass es wirklich auch Community-Effort ist und nicht nur zwei, drei Leute.

SPEAKER_03 49:48

Ja.

unknown 49:49

Cool.

SPEAKER_03 49:50

Du hast deine 120 oder 100 Co-Contributors angesprochen. Wie viele davon sind denn Cloud Code oder so? Also die Frage ist, wie viel AI steckt in Symphony AI drin und wie viel Handarbeit ist das so? Wie sieht so dein Entwickleralltag damit aus?

SPEAKER_01 50:09

Ich würde sagen tatsächlich, dass 90% des Codes, den ich heute schreibe, nicht wie ich bin, sondern halt gepromptet ist. Fi mal Daumen, vielleicht 95. Das ist tatsächlich am Anfang nicht so gewesen. Es hat sich ja jetzt auch, also das Projekt läuft jetzt zwei Jahre, das hat sich ja schon auch deutlich geändert. Es ist aber trotzdem so, dass, und das kommen wir wieder zu dem Punkt von vorhin, wo dieses, was ist jetzt das, was wir shippen und was ist eigentlich ein Extension-Punkt, weil ich dann schon auch irgendwann an dem Punkt war, wo ich dachte, okay, jetzt habe ich das hier, habe ich einfach nur gepromptet, das hat mich eine halbe Stunde gekostet, das nochmal schick zu machen. Ist das wirklich ein Feature oder ist das was, was jeder da selber rantackern kann? Und deshalb, ich glaube, die Sachen, die da jetzt drin sind, sind schon deutlich komplexer oder deutlich mehr handcraftet als das, was wir, also jetzt haben wir Skills drumherum, die dann irgendwie Doku nochmal glatt ziehen. Oder wenn wir jetzt irgendwie, wir haben in den 20 Vektor-Bridges haben wir eine Methode nachgezogen und dann haben wir gesagt, okay, das können wir erstmal über Agents parallelisieren und solche Sachen. Das passiert schon. Aber ich würde schon sagen, gerade rund um die Refactorings beim Stream, bei den Contracts und sowas, das ist schon doch noch sehr viel, zumindest selber nachgedacht vom Prompten.

SPEAKER_03 51:35

Das ist ja schon mal was.

SPEAKER_01 51:39

Also wenn wir da draußen die Prompten. Nee, aber wenn, ich weiß, dass es auch Kritik gab, tatsächlich an anderen Libraries, wo man sagt, okay, das wirkt alles sehr vibe-coded. Das würde mich tatsächlich schon treffen, wenn das jetzt das Assessment wäre von Symphonyi, weil das ist zumindest für den Teil, den ich beigesteuert habe, nicht nur Vibe, sondern auch Planung und Prompten.

SPEAKER_00 52:01

Carol, letzte Frage. Letzte Frage. Jetzt so ein bisschen so eine Metafrage, Lust auf eine Metafrage. Was hast du, sagen wir mal, über AI gelernt, als du diese Leiby geschrieben hast? Was gab es irgendwas, wo du. Kleine Frage zum Schluss. Die kann man vielleicht auch leicht beantworten. Willkommen jetzt zu diesem Podcast.

SPEAKER_01 52:31

Es ist eher nicht technisch, würde ich sagen. Tatsächlich, also diese Transformation, durch die wir drei hier laufen und die zuhören, das schon nicht ohne. Das ist tatsächlich aber eine emotionale Sache, glaube ich. Also das, was ich gelernt habe, ist, dass hoffentlich Promieren nicht mein Key Skill ist. Weil das ist nicht mehr so relevant. Das sage ich auch immer. Das ist hart, aber ich bin an dem Punkt, es gibt diesen einen Blogartikel über die five Steps of Losing Your Craft. Und ich bin, ich bin zwischen der Degression und der fünften Phase, dass man das überwunden hat. Aber ich glaube, es ist tatsächlich das, was ich, wenn du mich danach fragst, würde ich sagen, das habe ich gelernt.

SPEAKER_00 53:17

Und das, also das ist gerade die Library-Entwicklung oder das Beschäftigen mit diesem intensiven IT-Thema. Ja, genau.

SPEAKER_01 53:25

Also es ist wirklich eher dann der Zeitpunkt des Bauens, ja.

SPEAKER_00 53:33

Ja, ich glaube, so wird es. So wird es auf jeden Fall irgendwann uns allen gehen, würde ich sagen. Wahrscheinlich sind noch nicht alle da.

SPEAKER_03 53:42

Ich glaube, es haben aber auch noch gar nicht alle verstanden, die gerade programmieren, dass Programmieren gar nicht ihr Key-Skill ist. Die denken das halt so. Weil das ist ja das, was man die letzten, weiß ich nicht, 10, 20 Jahre irgendwie gemacht hat. Aber dass Code in die Tasten tippen halt nur das Endresultat eines sehr viel längeren, vorgelagerten Prozesses ist, das wird halt sehr oft übersehen. Und dann, wie halt Christopher auch gerade meinte, so da kommt dann halt die Erkenntnis, dass es das ja gar nicht ist, aber auch da muss man erstmal hinkommen.

SPEAKER_00 54:11

Ich antworte da jetzt nicht drauf, weil sonst haben wir wirklich die nächste Stunde den Podcast abgeleitet.

SPEAKER_02 54:17

Hören Sie die Fortsetzung.

SPEAKER_03 54:21

Ja. Dann meine klassische letzte Frage ist, Christopher, welche Frage haben wir dir nicht gestellt? Auf was warst du super vorbereitet, wo wolltest du unbedingt drüber sprechen? Und keiner hat dich danach gefragt.

SPEAKER_01 54:38

Eigentlich die eine ketterische Frage, warum machst du das in PHP? Die hätte ich erwartet. So, da waren wir ein bisschen, dann haben wir dran gestriffen. So, und ich glaube, eigentlich haben wir das Thema auch behandelt. Aber das ist so eine Frage, die ich schon höre.

unknown 54:53

Manchmal.

SPEAKER_03 54:54

Und was außer 20 Jahre Hingabe ist deine Antwort auf diese Frage.

SPEAKER_01 55:02

Die HTTP-APIs sind doch schon mal so einem Level, dass du gar keine Technologieentscheidung mehr machen musst. Also warum, also das HTTP-Layer ist ja da. Also das kannst du aus hier, du kannst auch das mit Curl und Bash bauen, wenn du willst. Also klar, und die Integration mit Bestandsanwendung. Klar.

SPEAKER_03 55:20

Ich sehe gerade irgendjemanden zu Hause sitzen, der seinen, weiß ich nicht, Cloud Code jetzt gerade promptet, bau mir ein AI-Agent in Curl und Bash. Und es wird wahrscheinlich funktionieren.

SPEAKER_02 55:30

Das ist instabil und schlecht, aber es wird funktionieren.

SPEAKER_00 55:33

Aber meine Antwort auf die Frage, wie viel Prozent des Internets läuft immer noch mit PHP? Also ich meine, alles, was richtig ist. Wie viel? 70%?

SPEAKER_01 55:42

Irgendwas, ich glaube 75%, 73, 77. Man muss auch dazu sagen, dass 43% davon WordPress ist. Also man sagt das immer gerne, 77% ist PHP, aber davon ist sehr viel WordPress, was auch PHP ist.

SPEAKER_03 56:00

Ich weiß gar nicht, ich meine, das hatten wir in der PHP-Folge auch schon so ein bisschen hin und her philosophiert, ne? Aber ich glaube einfach auch, es sind ja so ein paar sehr große Player, die noch einfach PHP machen. Allein wenn du überlegst, wie viel Anteil am Webtraffic Wikipedia alleine wahrscheinlich hat oder sowas. Ja, da geht viel hin. Ich warte immer noch darauf, dass hier jemand anruft und mit uns eine Folge machen will, wie viel PHP gerade noch bei Facebook irgendwie läuft, weil die ja auch sehr große Anwender sind, schräg-strich-Wahn. Die haben irgendwann aufgehört, darüber zu reden. Da ist jetzt so ein kleines Fragezeichen dran, aber die waren auch irgendwie immer ganz groß. Und so, man guckt halt nicht so drauf.

SPEAKER_00 56:36

Man hat es nicht mehr so im Schirm irgendwie.

SPEAKER_01 56:39

Aber ich glaube, gerade im E-Commerce-Bereich und CMS-Bereich, gerade CMS und Gen AI macht schon auch einfach erstmal Sinn. Das passt schon, glaube ich.

SPEAKER_03 56:51

Cool, cool. Dann wären wir ja im Prinzip schon fast durch, oder Gerald?

SPEAKER_00 56:58

Ja. Aber es kommen noch die Picks of the Day. So ist das. Hab ich das richtig gesagt? Pick of the Day? Nein.

SPEAKER_03 57:06

Wir sagen das richtig. Ich glaube, Fabi sagt das immer falsch, gell? Was sollte denn? Wir bläben jetzt hier einfach mal Fabi.

SPEAKER_00 57:12

Fabi sagt immer Pick of the Days. Und das ist ja. Nee, Picks of the Day. Aber es heißt, der auf der Website hat einfach Pick of the Day.

SPEAKER_03 57:37

Gefühlt, wenn ich diese Folgen höre, ist es ja jingelt ultra schnell. Jedes Mal, wenn ich da sitze und warte, bis er durchgelaufen ist, kommt er mir unglaublich lange vor. So, Garelt, hast du die letzten 60 Minuten genutzt, um deine Hausaufgaben zu machen? Natürlich.

SPEAKER_00 57:53

Dann darfst du anfangen. Ich bitte, was du auch gut schon erwähnt hast, Christopher, und zwar ein Newsletter, den von den fünf, die ich habe, die ich momentan lese, die ich nämlich sehr cool finde und zwar aus dem Grund, den habe ich abonniert zu einer Zeit, wo ich in dieser Depressionsphase war, würde ich sagen, was so eher angeht. Und dieser Newsletter hat er es geschafft, wieder für mich ein sehr viel positiveres Licht drauf zu werfen, weil es einfach irgendwie insgesamt positiver diese Dinge schaut, aber auch so sehr emotional und persönlich geschrieben ist. Und zwar ist das der Newsletter von, und ich sage den Namen immer falsch, Thorsten Ball. Thorsten Ball ist, soweit ich weiß, oder war ein Entwickler von AMP. Und du musst, glaube ich, kurz erklären, was AMP ist. Ja, ich weiß es selber nicht so ganz genau, ehrlich gesagt. Also es ist halt auf jeden Fall auch was mit AI-Agents zu tun. Wenn du es weißt, dann sag du es bitte. Also ich hätte AMP einfach abgespeichert als so Coding-Agent. Ja, habe ich auch, aber es war mir nicht sicher. Ich dachte schon, AMP-Code. Ja, okay. Es sieht aus wie ein Cloud Code für coole.

SPEAKER_02 59:10

Ich stehe übrigens bei AMP, stehe ich, glaube ich, seit, ich will nicht lügen, aber drei oder vier Monaten mindestens auf der Warteliste. Und ich krieg ab und zu so eine E-Mail mit, hey, unsere Warteliste ist voll voll und übrigens deine E-Mail-Adresse sieht gar nicht echt aus. Kannst du dich bitte nochmal bewerben?

unknown 59:29

Was?

SPEAKER_00 59:29

Es gibt eine Warteliste.

SPEAKER_03 59:31

Ja, auf jeden Fall, die Warteliste ist nur für den kostenlosen Access von MP. Wenn du bezahlen willst, die stehen auch in der E-Mail.

SPEAKER_00 59:37

Wenn du bezahlen willst, kannst du sofort irgendwie loslegen. Moment, aber hier kann man einfach, das kann man einfach installieren. Ja, und dann brauchst du einen Account. Code kannst du auch einfach installieren, hilft dir nur nichts. Auf jeden Fall dieser Newsletter heißt Joy ⁇ Curiosity, der kommt irgendwie einmal die Woche und dann beschreibt er am Anfang einmal so, was ihn beschäftigt hat und dann halt irgendwie ganz cool, so was hat der gelesen, was hat er miterlebt und so und dann immer seine Brille darauf. Und man bekommt schon immer ganz gutes Gefühl, so worum es in dem Artikel geht und es reicht wahrscheinlich auch schon, das zu lesen, aber oft macht er das so gut, dass man auch Lust bekommt, da noch weiter reinzugehen. Und wie gesagt, es ist sehr, es ist sehr, er ist auch ein Engineer und er ist sehr so engineer-positiv, sage ich mal, was die AR-Welt angeht. Und mir tut es gut.

SPEAKER_03 1:00:23

Aber ist er positiv, so wie wir das hier manchmal sind, oder ist er so ein Fanboy wie Dennis?

SPEAKER_00 1:00:29

Nee, nee, nee, nee. Also sehr konstruktiv positiv. Positiv. Also er versucht, es realistisch zu betrachten und dann zu gucken, was, was ist unsere Aufgabe in dieser Welt. Okay. Und das ist cool. Nice. Nehmen wir mit.

SPEAKER_03 1:00:42

Nehmen wir mit.

SPEAKER_01 1:00:43

Christopher, was hast du so am Start? Ich habe tatsächlich ein Buch. Ich weiß gar nicht, ob das hier mit Video ist oder nicht. Das heißt Sketchnotes in IT. Oh, ja, nice. Und das ist tatsächlich für die Leute, die, also gerade jetzt, wenn man auch noch mit Menschen zusammenarbeitet, ist das Visualisieren von Software-Architektur gerade super hilfreich.

SPEAKER_03 1:01:02

Haben das alle gehört, wie Christopher gesagt hat, wenn ihr noch mit Menschen zusammenarbeitet.

SPEAKER_02 1:01:10

Kleines Wort leistet sehr viel in diesem Satz.

SPEAKER_01 1:01:14

Aber deshalb trotzdem, deshalb finde ich das als Kontrast sehr wichtig. Also Visualisierung, das ist von Lisa Maria Moritz, ich glaube Schäfer heutzutage. Und das ist gerade, wenn man dann selber noch irgendwie drei linke Hände hat beim Miro oder ExcaliDraw oder was auch immer, ist das eine sehr gute Step-by-Step-Anleitung, wie man manchmal dann Dinge, also wirklich in einem Buch, wirklich für Leute wie mich erklärt, wie man Dinge visualisieren kann. Und das ist tatsächlich sehr hilfreich für uns, würde ich sagen.

SPEAKER_03 1:01:47

Ich habe sie mal darüber sprechen sehen und ich muss immer sagen, ich finde Leute, die auch so auf Konferenzen von Sessions oder sowas, die ordentliche Sketchnotes mitschreiben können, so live, das ist ein abgefahrener Skill. Das ist ein abgefahrener Skill.

SPEAKER_01 1:02:00

Ich mache immer die Visuals für Software-Architektur im Stream, ne?

SPEAKER_03 1:02:05

Bei Eberhard Wolf, ne?

SPEAKER_01 1:02:07

Ja, ganz klar.

SPEAKER_00 1:02:08

Warte mal, Moment, sie hat einen Stream, wo sie das macht, oder was?

SPEAKER_03 1:02:10

Nein, nein, Eberhard Wolf hat einen Stream über Softwarearchitektur und sie macht quasi die Grafiken. Also er spricht über Architektur und parallel gibt es Grafiken und die kommen von ihr. Okay. Und ich finde, Sketchnotes ist so ein abgefahrener Skill. Ich habe bei der letzten Konferenz, wo ich war, habe ich einfach gedacht, okay, ich schreibe hier von Hand mit und gehe danach einfach hier zu Nanobanana und sage, ey, kannst du mir meine eigenen Notizen nicht mal in coole Sketchnotes verwandeln? Und das hat das nicht hingehen, also es macht natürlich irgendwas, aber bei weitem nichts, was so cool ist wie Leute, die irgendwie richtig ordentlich live Sketchnotes schreiben können. Ich bewundere Leute, die das können. Und auf der Suchertest-Konferenz, wo ich ja auch schon länger immer rumhänge, es gibt jedes Jahr Workshops zu Sketchnotes, seit weiß ich nicht, zehn Jahren oder so. Und jedes Mal gehe ich da rein und jedes Mal komme ich raus und bin so, nein, ich kann es einfach nicht. Also ich habe keine Ahnung.

SPEAKER_01 1:03:02

Aber es ist irgendwie, es ist ein Skill, den ich auch gerne, also ja, ich bin ein bisschen neidisch. Ich hoffe, wenn ich das Buch dann durch habe und wenn ich es. Man muss es einfach konsequent machen. Und dann ist es wahrscheinlich irgendwann vielleicht.

SPEAKER_00 1:03:13

Aber ich finde es allein schon spannend, weil ich das Gefühl habe, sowas wird noch relevanter, auch was die Kommunikation mit Agents angeht. Weil so irgendwann mehr High-Level über den Code zu sprechen, wird es halt irgendwann sein, glaube ich, wenn du genug Confidence hast, dass die Funktion, die er baut, schon gut genug ist. Wer weiß, ja.

SPEAKER_03 1:03:33

Auch ein Punkt. Mein Pick hat auch was mit AI zu tun. Und zwar, äh, Gareth wird das schon kennen, wobei, andersrum, ich leite das anders ein. Mein Pick ist gar kein Pick. Mein Pick ist ein Tool, was Gareth jetzt gleich kennt, wenn ich es vorstelle, und zwar Planetator. Wir haben es letzte Woche hier auch besprochen, glaube ich, bei uns in der ER-Runde hier bei Lotum. Und zwar ist es ein Tool, was dir ermöglicht, in den Plänen von Cloud Code etc. quasi rumzuschreiben, da drin zu annotieren und so quasi nochmal ein paar Korrekturläufe zu machen, bevor die AI dann wirklich im Execution-Modus anfängt, das quasi alles umzusetzen. Und ich bin mit Planetator nicht zufrieden. Deshalb ist es nur so ein halber Pick. Aber ich hätte gerne ein Tool dieser Art. Also Bergruf. Ja, das ist ein Aufruf. Schmeißt mir eure Picks irgendwie entsprechend zu. Weil ich behaupte ja nach wie vor, die einzige IDE, die das richtig gelöst hat, ist irgendwie immer noch Antigravity. Die will man halt aus anderen Gründen nicht benutzen, aber der Plan-Modus, den sie haben, der ist halt abgefallen gut mit. Du redest mit dem Agent, du kannst in dem Plan rumschreiben, du kannst ihn annotieren, du kannst Assets dazu fügen. Der Plan ist halt wirklich ein First-Class Citizen sozusagen in der IDE irgendwie drin, ja, und nicht nur so ein Ephemeral-Ding, was irgendwie in deinem Chatverlauf drin hängt. Und das finde ich halt super wichtig. Also je größer die Features werden, die wir jetzt so langsam mit diesen Tools bauen und je mehr wir ihnen irgendwie zutrauen, desto wichtiger wird ja dieser Plan eigentlich als Artefakt. Und mir fehlt irgendwie immer noch das Tooling, um damit sauber zu arbeiten. Planetator ist schon deutlich besser als das, was die meisten dieser Tools irgendwie von Haus aus mitschippen. Aber ich habe das Gefühl, da würde noch so viel mehr gehen. Und vielleicht hat da draußen schon irgendjemand was gebaut oder gesehen oder keine Ahnung, dann kann er es gerne in meine Richtung schicken. Ansonsten Leute, die ähnlich unter Plänen leiden wie ich, die können sich gerne mal Planetator anschauen. Planetator.ai planen mit Doppel-N, so wie Annotator und so.

SPEAKER_00 1:05:40

Ja. Du musst das nicht, gell? Ich habe es installiert und aber noch nicht wirklich benutzt. Habe ich es gerade komplett verpasst oder kannst du nochmal sagen, was du daran nicht magst? Okay.

SPEAKER_03 1:05:50

Also, um einmal zu erklären, wieso der Flow ist. Also du installierst das Plugin für Cloud Code zum Beispiel mit Planetator, du installierst Planetator. Und in dem Moment, wo dir Cloud Code im Prinzip eigentlich den Plan anzeigen würde, geht so ein Browserfenster auf, so ein kleiner lokaler Server läuft da bei dir und der Plan wird angezeigt. Und dann kannst du so ein paar Kommentare da drin verlassen, verfassen und dann kannst du ihm quasi einmal nochmal Retour drüberlaufen lassen und dann kannst du das so oft iterieren, wie du möchtest. Ich hätte zum Beispiel gerne, dass ich Dateien anfügen kann, dass ich in dem Plan selber direkt rumschreiben kann, ohne dass ich das indirekt über Kommentare und weiteres irgendwie mache, dass der Plan vielleicht am Ende doch irgendwo auch in meinem Pfeilsystem, also natürlich lebt er im Fallsystem, ich hätte ihn gerne als Teil des Projektes vielleicht auch, ja, gerade um vielleicht an dem Plan kollaborieren zu können, um an dem Plan irgendwie als um den längerfristig aufzuheben im Repository. Also es gibt, glaube ich, so viele Sachen, die man da irgendwie noch machen kann. Und gefühlt hat das halt noch niemand so wirklich geknackt, ja. Und ich glaube auch, Planetator, da müssten wir Dennis mal fragen, wie sich Planetator zusammen mit so Orchestrierungen und sowas, mit Conductor oder so verhält, könnte man sich auch mal anschauen. Aber ja, deswegen so ein halber Pick, Planetator, schon ganz cool. Ich hätte gerne noch was, was deutlich cooler ist, aber solange es das nicht gibt oder mir keiner geschickt hat, nehme ich auch weiter Planetator.

SPEAKER_00 1:07:16

Bauch selber.

SPEAKER_03 1:07:17

Ja, also das hat ja auch irgendjemand in unserer Session gesagt, ich weiß nicht, Etienne oder so, der meinte, da kann man ja auch irgendwie alles selber machen. Aber also ganz ehrlich, da gibt es, hast du nicht dieses Meme mal gesehen, was vor ein paar Monaten oder so rumging, so ja, ich habe all meine Software as a Service Subscriptions losgeworden und zahle jetzt nur noch 12.000 Euro im Monat an Tokens? Nein. Das will ich halt, also ich finde es immer noch cool, dass sich Leute um Stück Software Gedanken machen, die mehr Domänenwissen mitbringen, ein viel größeres Incentive haben, dass das funktioniert. So eher spezialisierte Software und Leute, die sich darum kümmern, hat alles irgendwie ihren Sinn. Ich sehe keine Zukunft, in der jeder sein scheiß Stück Software, das er so braucht, irgendwie selber schreibt. Aber wir reden in zehn Jahren nochmal.

SPEAKER_00 1:08:01

Vielleicht in sechs Monaten.

SPEAKER_03 1:08:06

Lachen wir dann alle nur noch drüber.

SPEAKER_00 1:08:10

Alright. Das war es, glaube ich. Spaß gemacht.

SPEAKER_03 1:08:14

Ja. Danke, Christopher. Es war ein super interessantes Gespräch mit erschreckend wenig PHP-Anteil. Ich habe schon gedacht, wir verlieren die Hörer irgendwo zwischendrin, aber ich glaube, es war eine sehr wertvolle Diskussion um viele von diesen Architekturen und Grundsatzfragen, die man sich halt irgendwie stellen muss, wenn man das Ganze A aufzieht und B irgendwie benutzen will. Safe. Und auch nicht. Egal vielleicht nicht, aber zweitrangig zumindest so vielleicht. Und deswegen glaube ich das super wertvoll so. Wenn ihr Fragen, Anregungen, Kritik, Vorschläge habt, dann immer gerne an podcast.programmier.bar oder ihr kommt auf unseren super coolen Discord-Server. Wir freuen uns immer über Feedback und insbesondere über Vorschläge, Alternativen zu Planetator. Die nehmen wir diese Woche extra gerne mit. Und ansonsten sprechen wir uns nächste Woche wieder. Bis dahin, tausend Dank, tausend Dank Harald und wie gesagt, tausend Dank Christopher. Schön, dass du wieder da warst. Ja, danke auch. Wir sehen uns bestimmt nochmal wieder hier. Macht's gut. Bis dann. Ciao, ciao.