Deep Dive 209 –

AI Libraries mit Christopher Hertel

09.06.2026

// Podcast
// Deep Dive 209

Shownotes

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.

Download

/transkript/programmierbar/deep-dive-209-ai-libraries-mit-christopher-hertel

Jan: Hallo und herzlich willkommen zu einem neuen Deep Dive hier in der programmier.bar. Ich bin wie immer für euch der Young und neben mir in der linke Sofaecke sitzt
Garrelt: der Gareth. Du bist gar nicht in
Jan: der linken Ecke, bist in der rechten Ecke.
Garrelt: Nee, nee, von mir schon in der linken.
Jan: Ja, ja. Also so meine ich das ja auch. So mein ich das auch. Und wir haben mit uns im virtuellen Studio heute den Christopher Hertel. Hallo Christopher, schön, dass Du da bist.
Christopher: Hi, danke für die Einladung.
Jan: Christopher, Du bist nicht ohne Grund hier. Du bist ein sehr Cool. Cool. Mist, das hätte 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 Programmiercode war letztes Jahr, ja, sondern weil er sich auch auf sehr vielen anderen Konferenzen runter. Christoph, ich hab vorhin mal versucht nachzuschauen. Ich hab's nicht 100 Prozent rekonstruieren können, aber ich glaube, wir haben das 1. Mal gemeinsam 2019 auf der Bühne gestanden auf der fünften Live in Berlin. In Berlin.
Christopher: Ah okay. Also das ist eine fatal. Das
Jan: sind so meine, Ja, da war, das stimmt. Oh, das, ich wusste, es war früher. Ich wusste, ich hab's aber in meiner Cameraole einfach nicht mehr gefunden.
Christopher: Das war das Dach.
Jan: Ich bin vorhin so in der Mittagspause so am Handy einfach stupide stundenlang gescrollt und dachte so, wo waren wir da gemeinsam?
Garrelt: Aber ihr kennt auch schon, also ihr kennt euch seitdem. Also ihr habt euch da getroffen und gequatscht miteinander.
Jan: Also den Christopher kannst Du eigentlich nicht nicht kennen, wenn Du dich irgendwie in der deutschen PHP Community Ja,
Garrelt: okay. Treibst.
Christopher: Ja, okay.
Garrelt: Das verstehe ich, ja.
Jan: Also ich kannte ihn schon bevor ich ihn kannte sozusagen.
Garrelt: Okay, aber ich mein, ob Du ihn kennst oder ihr euch kennt, ist ja noch 'n großer Unterschied.
Jan: Das das ist das Ja, ich
Christopher: glaube, bei der bei der Phantasialand 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.
Jan: Ich war nicht schlecht genug, als dass er nicht in der Zeit hätte lieber Achterbahn gefahren oder so. Das das ist ja eigentlich das Kompliment, weißt Du?
Garrelt: Aber das weiß er vorher nicht. Genau, Du
Jan: kannst auch jedes Kompliment zunimmst.
Garrelt: Wenn Du dich selbst selbst komplementierst, dann So. Lade lädt lädt das ein.
Jan: 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 das sich quasi hervorragend anbietet, darüber zu sprechen und darüber son bisschen Allgemeineres vielleicht auch abzuleiten. Aber bevor wir tief ins Thema einsteigen, Christopher, vielleicht kannst Du einmal ganz kurz, also ganz kurz geht's wahrscheinlich nicht, weil's schon 'n bisschen größere Nummer ist, abreißen so. Was ist Symphony AI? Was habt ihr euch dabei gedacht und was ist so der aktuelle Stand?
Christopher: Klar. Symphony AI ist tatsächlich ein Projekt, was anfängt mit 'ner niedrigen Ebene. Wir haben so. Grob gesagt, ist da erst mal 'n Satz an unterschiedlichen PHP Komponenten, AI basierte Feature in PHP Anwendungen zu bauen. So. Ist, glaub ich, son bisschen basiert auch irgend diesem Gamechanger der der API basierten in Firance, ne. Dadurch, dass 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, so was gut in PHP zu machen. Und wir haben so Komponenten, die eher dafür da sind, eine Abstraktionsschicht reinzuziehen für, vor für Vektor Stores und vielleicht auch son bisschen andere andere Integration wie zum Beispiel Tools. Und dann haben wir halt son Midlevel, würd ich sagen, was wirklich dann so Agent Komponente ist oder Chat. Und dann natürlich Symphony Framework Integration ist 'n Opt in. Symphony versuchen wir immer relativ agnostisch oder Framework agnostisch zu bauen, dass man auch dann, wenn man wenn man, weiß nicht, in unterwegs ist oder mit unterwegs ist, auch Symphony AI nutzen kann. So. So weit so das Grobe, würd ich sagen.
Jan: Okay. Und dann lass uns doch das vielleicht direkt als Einstieg so nutzen. Du hast ja schon angesprochen, dass so Inference als als API so der der große Gamechanger dafür war und ja im Prinzip auch 'n Requirement, dass es diese Libraries auch irgendwie alle geben kann. Und da will ich vielleicht mal die ketzerische Frage zum Eingang stellen. So. Oh ja. Ja. Doch, was also was macht denn dieses Library am Ende aus, außer son sehr dünner Rapper Curl zu sein? Weil Also wenn man sich diese Das ist ja diese ganzen API Dokumentation von OpenAI oder Intropic oder so was anguckt, ne, dann ist es ja auf den ersten Blick wirklich nicht viel mehr als, na ja, mach da halt mal son Post request irgendwie hin und dann riechst Du schon irgendwas Inferites zurück. Wieso brauche ich denn da überhaupt 'n Library?
Christopher: Du hättest die Frage noch ketzerische stellen können, wenn Du sagst, warum warum kann ich denn nicht einfach LLIT LLNM nehmen? So, weil das ist ja sozusagen son son Proxy, der ist alles weg abstrahiert. Ja. Aber es ist ist fair, ne. Also tatsächlich die die die Value Proposition für uns ist bei der Komponente die Abstraktion. Das heißt, ich will meinen Anwendungscode so bauen, dass egal, ob ich das jetzt mit Vertex Array oder mit oder Gemini, anthropic, you name it mache, dass ich den Code an sich nicht anders machen muss, sondern nur die Konfiguration dazu. Ja. Und das ist erst mal nur 'n Rapper die HTP API. Und das 2. Feature, was wir eigentlich reinbringen, ist eine Strukturierung durch Datenobjekte. Das heißt, Du musst an der Stelle jetzt oder JSON durch die Gegend werfen, sondern Du kannst sagen, ich hab hier meine Message. Ich hab hier mein mein Image oder mein PDF und das wirft rein und das bauen wir dann durch den in die JSON Dokumente Ist aber tatsächlich erst mal 'n bisschen schlanker und dann nervig hätt ich fast gesagt, aber der komplexere Teil ist dann so was wie Stream Handling, ne. Und das ist tatsächlich was, wo's dann losgeht, wo Du vielleicht dann doch weniger Bock hast, das selber zu machen, auch mit Köln.
Garrelt: Und das unterstützt sie auch schon, verstehe ich. Richtig, oder?
Christopher: Das Streamhandling, ja, wir sind immer noch, also die Frage hab ich am Anfang gar nicht so voll beantwortet, ne, wo sind wir jetzt grade? Wir sind tatsächlich noch vor dem 1, v 1 so. Das heißt, wir sind noch tatsächlich dabei, diese die Contracts für die Asymphony Backwatch Compatability Promis klar zu kriegen. Und besonders, wenn's dann darum geht, wie man Reasoning im Stream rauskriegt zum Beispiel. Also grade so Thinking Content, die das das fliegt 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 'n Benefit davon hast. Ist es gar nicht so ohne, wenn man das für Open AI, Entropic und Gemini also möglichst agnostisch haben will. Da sind wir noch dran, ja.
Jan: Mit dem Reasoning sprichst Du vielleicht schon eine ganz interessante Fragestellung an. Jetzt ist ja, Inference funktioniert ja erst mal überall gleich so. Text rein, Text zurück, so. 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 Toolcalling, wie machen sie Reasoning, ja, wie machen sie vielleicht auch File Uploads hast Du eben schon angesprochen, so. Und da stelle ich mir son bisschen die Frage, jetzt hast Du gesagt, ihr wollt das alles so vereinheitlichen, aber wie unterschiedlich ist denn dieses Ökosystem überhaupt? Also wie wie schwer habt ihr das da an der Stelle? Oder gibt's da schon son De facto Standard, der sich quasi durchgesetzt hat?
Christopher: Es gibt, glaube ich, da 2 2 unterschiedliche Ebenen. Also wenn wir jetzt einmal nur die Impress anschauen, dann kann man schon sagen, dass ich, durch die Compleitions API, die die, also die Chat Compleitions, die Open AI eingeführt hat, da sind ziemlich viele direkt hinterhergelaufen und haben das ähnlich gemacht, dann auch mit den SDKs kompatibel zu sein. Und das nächste Level war dann eigentlich Open Responces, so. Das ist so diese Response zu API, die auch von Open AI zusammen mit, auch zusammen mit Huggingface, glaub ich, standardisiert wurde und auch 'n bisschen neutraler die Spezifikation gelauncht ist. Das heißt, auf dem Teil geht das schon eigentlich ganz gut klar inzwischen. Da hat sich das 'n bisschen konsolidiert über das Ökosystem. Das macht uns das natürlich bisschen einfacher. Es ist tatsächlich aber immer noch so, dass dann manche da gerne rausfallen, ne. Ob das jetzt so was ist wie wie oder Gemini insgesamt, da gibt's einfach noch mal andere andere Contracts. Und das versuchen wir tatsächlich dann einfach direkt mit abzubilden. Und ein Layer, der auch noch mit dazukommt, ist so was wie 'n Modelkatalog, was wir haben, wo man dann, ist es halt wirklich plattformspezifisch oder providerspezifisch das wirklich laden kann. So, und das ist tatsächlich auch noch nicht standardisiert. Und die 2. Ebene, die wir haben an der Stelle ist das, was dann zum Beispiel Open AI mit der Assistance API macht, wo man dann auch wirklich Sessions aufmachen kann, vorher hochladen kann, 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 Businesslogik wegzudelegieren in den Service. So, das heißt, ich würd meinen Agent lieber selber bauen und meine Fies lieber selber hosten als Open AI zum Beispiel dann oder 'n Azure Indexer zu benutzen zum Beispiel.
Jan: Das wär
Garrelt: jetzt auch irgendwie mal eine Vorstellung, wie man das bauen müsste, nicht son Bänder Log in zu haben. Was aber auch eigentlich gehen müsste, oder? Dass Du sagst, okay, Du bietest halt eine Library, die dir das anbietet, dass Du das irgendwo lokal speicherst und dann irgendwie in 'ner strukturierten Weise immer in den Kontext von der gibt's oder? Ist also ist vorstellbar, oder?
Christopher: Voll, voll. Es ist nur die Frage, auf welches welches Produkt Du sozusagen letzten Endes, ne. Wenn Du sagst, okay, ich will will will die BadRock Services oder die die Azure Assistant oder Open AI Assistance Feature dafür nehmen. Oder ich will ich will nur die kombinieren mit 'nem Milesearch oder was auch immer ich selber an der Infrastruktur hab. So, und da sind wir, glaub ich, deutlich mehr in dem, okay, ich will die selber kombinieren Feld, als dass wir jetzt wirklich noch mal versuchen, so Product APIs über Google Batrock und Open AI zu zu vereinheitlichen.
Jan: Ja. 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 wieder baue, dann brauche ich ja 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's andere Tools für?
Christopher: Die Frage ist gar nicht so einfach, weil das ja auch fürn Findungsprozess für uns war beziehungsweise ist. Jetzt grade mit Bezug auf die 1 0, die wir möglichst bald mal haben wollen, ist natürlich dann auch so die Frage, was ist was ist eigentlich Du musst noch mal 'n wirklich klarziehen, so. Und ich kann euch jetzt, sag ich mal, so viermal noch 'n paar Wochen vor der 1 0 sagen, wo ich jetzt grade bin, aber würde nicht garantieren, dass es so bleibt. Also meiner Meinung nach ist es so tatsächlich, dass wir die abstrahieren, sowohl HTTP als auch Datenobjekte und da gar nicht uns auf Language Models einschränken, ne. Hogingface bei der Inference Sub API kannst Du alles mit Input Output ist es egal, kann Text sein, kann sein, kann Image sein und so weiter. Das haben wir alles so direkt mit drin. Und ich würde aber tatsächlich nicht nicht so weit gehen, zu sagen, wir wollen auch in der Agent Komponente Memory und und Skills und das, was man sozusagen aus anderen argentischen Produkten wirklich kennt als Feature, dass wir das, also wir sind nicht oder oder dein dein Framework so. Sondern da haben wir jetzt grade eine Verhandlung, sag ich mal, in in dem auch im Maintenance, was an Extension Points ist okay, was an Feature gehört eigentlich dann in die Produkte? Und es ist tatsächlich, die Extension Punkte, würd ich sagen, sind immer noch dann Call. Du kannst dich in den Tool reinhängen. Du kannst dich in 'n Agent Input Output Plattform reinhängen über Events. Aber ob wir jetzt wirklich Chat und Memory und all diese Dinge mitliefern, eher nicht. Sondern Willst
Jan: Du jetzt da mal mitnehmen in die in die Diskussion? Also was waren denn so die Argumente dafür und und was waren die Argumente dagegen und was war am Ende ausschlaggebend?
Christopher: Gute Argumente dafür sind, das ist tatsächlich auch son bisschen, ne. Also wenn Du wenn Du dir anschaust, wie unterschiedliche Agent Frameworks grade wachsen, gibt's links und rechts auch 'n PHP, gibt's da inzwischen eine Handvoll mit Elefant und Laral AI SDK sitzt auf sitzt auf, glaub ich, und dann haben wir Neural AI. Das ist natürlich alles auch alles total cool zu sehen, dass so viel los ist. Und dann ist natürlich auch 'n gewisser Anreiz dabei, mehr Feature zu haben. Und auf der anderen Seite ist das halt Open Source. Ich ich bin ja jetzt nicht Vollzeitsynty AI ID Developer. So, das heißt auch auch, dass man das nachhaltig macht, ist son Aspekt. Mhm. Und 'n ganz spannenden Aspekt, den wir jetzt hatten, auch in der Diskussion zuletzt ist, In diesen argentischen Zeiten von Cloud Code, wie viel musst Du eigentlich schippen 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 'nem 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 son, den wir generell noch mal so in Open Source vielleicht sehen, dass Feature Reichtum an sich vielleicht gar nicht so Ausland geben will, sondern dass die Extension Points, dass die sind und eine ermöglichen, Dinge reinzuwerfen in das Ding. Und das ist das, wo ich jetzt grade bin, dass ich sage, okay, vielleicht ist so was wie 'n Tool an gar nicht so relevant, wenn ich einfach meine selber rein tacke über die Extension Points, die wir haben rund Tool Calls. So, das ist noch mal son Konzern, der einfach neu ist für mich in dieser dieser Welt.
Garrelt: Da stelle ich mir direkt die Frage, was ist denn Also das ist geht vielleicht 'n bisschen auf eine fundamentalere Ebene, aber wenn die AI das so viel also so gut selber machen kann, dann könnte man da so argumentieren, dass die Library nicht mal sinnvoll ist oder siehst Du diese Basisfunktion immer noch als sehr, sehr wertvoll oder essenziell, wenn Du dieses Argument noch ketzer als ich?
Christopher: Ja, nee, finde ich gut, finde ich gut, weil das das sind genau die Fragen, die natürlich, das beschäftigt uns alle, ne. Also Mhm. Brauchst brauchst Du zukünftig noch diese ganzen 1500 NPM Dependencies oder kannst Du das einfach machen selber? Mhm. Ich glaube, mein Argument an der Stelle wär, Du willst in deiner Codebase bestimmte Konzerns lösen, bestimmte nicht. Manche willst Du kognitiv selber managen Mhm. Und manche nicht. Wenn Du jetzt sagst, okay, ich hab einen Memory, ich bau 'n Produkt, das hat 'n Agent Memory, dann hast Du klare Requirements dazu. Mhm. Das heißt, da gehört dann die kognitive Lastmangel danach zu dir. Mhm.
Jan: So,
Christopher: aber der Extension Punkt, wie Du dich da damit reinhängst in den Agent. Du sagst, ich will, also 'n Agent, die langweiligste, also meine Erklärung fürn Agent ist, glaub ich, die langweiligste, die Du haben kannst, ist 'n Iterator über LLMs und Tool Calls. So. Mehr ist das nicht, ne. Erst durch das, was im State passiert, den Kontext wird's halt irgendwie cool. Und ich glaube, das das kannst Du, das willst Du nicht selber lösen. Mhm. Ja. Klar könntest Du jetzt sagen, ich will jetzt die Streamhandling und Aber bis Du das zurechtgeprompt hast? Das kann 'n bisschen dauern.
Garrelt: Okay, da ist ja son bisschen die die Basis des Arguments so, okay, Du bist ja am Ende immer noch verantwortlich dafür, was der Agent dir ausspuckt und ob das dann auch funktioniert. So und klar, der Kram, der einfach funktionieren soll, ist wahrscheinlich sinnvoll, den auszulagern, 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.
Jan: Du hast gesagt, ihr seid grade auf dem Weg zur 1 0 und vielleicht bist Du vorher draußen, also ich hab's grad gar nicht aufm Kalender. Vielleicht ist dann schon die 1 0 draußen.
Christopher: Oh, stimmt. Wann wann wann ist das auch nein? Da müssen wir nur kurz
Jan: Das Das kann ich gleich noch mal unauffällig nachschauen, während Du die nächste Frage beantworten wolltest, weil weil ich mir auch Gedanken darüber gemacht hab, wie wie man so einen QA Prozess in sonem Library halt abbilden kann, ja? Weil natürlich willst Du auch 'n bisschen bisschen testen und so, aber das ist ja alles so sehr nicht deterministisch, was da passiert und wir selbst haben, also weiß nicht, wer das spricht für dich, aber ich hab jetzt noch kein großes AI Projekt gebaut und schon gar keins mit Tests. Ich frage mich, wie wie macht man das denn? Also ne, jetzt hast Du irgendwie hier deine ganzen Adapter- und Abstraktionenschichten und so was und dann willst Du das 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 ihr jetzt mit irgendwie 20 verschiedenen APIs sprecht, wer bezahlt denn das? So, weil Tokens kosten ja auch Geld am Ende des Tages.
Christopher: Ja. Aber supernal ist die Antwort auch, ne. Es geht halt mit 'ner Kreditkarte, so. Mhm. Also tatsächlich ist es so, dass ich ich hab einen einen Anfall rumliegen mit 70 verschiedenen und Token und hab, also wir haben Also tatsächlich ist es 'n, wenn Du eine neue Bridge bei uns reinbringst, ob das jetzt fürn Vektorstore ist, dann arbeitest Du das das Setup. Und wenn Du 'n neuen Provider reinbringst und auch wenn das der ist, der vom französischen, dann ist geht's darum, dass am Schluss da 'n Exempel liegt, was ausführbar ist und ich dann auch irgendwie 'n API Token dafür krieg, so. Das heißt, ich hab 'n 'n Runner, der bei mir lokal und mit 'nem Skill halt parallelisiert diese 260 Examples, die wir inzwischen für die unterschiedlichen Vektorstores und Streaming mit und und Streaming mit Tool Call by OpenAI und Eleven Labs hier und alles ausführt. Also im Moment ist das 'n sehr naiver, aber der beste Approach, den ich den ich hab, tatsächlich.
Garrelt: Boah, also das interessiert mich jetzt voll, was also was sind das für 260
Jan: Ich dachte, Du wolltest sonst ein Feil ran oder so
Garrelt: und Feil. Die könntest Du überhaupt mal schicken. Nee, mal, also vor allen Dingen vor allen Dingen Vector Stores, also wie was machen die in der Library?
Christopher: Wir haben wir haben tatsächlich in der Store Komponente, da haben wir quasi sone Indexing Pipeline. Das heißt, es geht los mit, da liegen irgendwelche Markdownfiles oder in Memory Und die werden dann, gibt's eine Transformersicht, wo Du dann sagen kannst, okay, ich will's schanken. Und dann gibt's 'n hoher, 'n Vektor, der dann ganz klassisch aus den Dokumenten die die Embeddings macht und dann geht's in den Store. Das ist unser Indexing Pipeline und für die Vektorstores haben wir dann tatsächlich einmal Integration Tests, die wirklich auf dem auf dem Docker gebouteten Image arbeiten, wenn wir's dann haben. Ansonsten bei ist es, nee, gibt inzwischen liebsten Mock Image. Und für diese Rack Indexing Pipeline haben wir tatsächlich dann auch Examples, die vom Marktdown File bis hin zum Query am Schluss das einmal durchtackern. So, das ist 'n bisschen bisschen aufwendig. Aber mein Selling Point an der Stelle ist halt auch, wenn Du jetzt sagst, ich möchte mit 5 NIR und Pincone und Markdownfiles einmal Rack sehen, gehst Du in das Exempel und kannst von oben bis unten durchschauen. Mhm.
Jan: Diese ganzen Examples und Test Cases, nur den ersten Teil der Frage noch mal aufzumachen, wie wie testet ihr das denn am Ende? Aber wie gesagt, der der Output ist ja nicht deterministisch. Und wie sieht son CI Durchlauf bei euch am Ende aus, bis wirklich alle Tests auf grün sind und gesagt wird, ja, das das ist okay, was da zurückkommt?
Christopher: Also für 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 sonen reinschaust, dann siehst Du am Schluss sind da 400 Checks durchgelaufen fürn Change. So, also in diese so hart wird das multipliziert, weil das einfach sehr viele Integration Bridges sind. Und da haben wir Integration Tests auch mit Docker, was wir drin nicht haben, außer es gibt für OpenAI gibt's einen manuellen Trigger, wirklich auch API basierte Tests zu machen. Das behalten wir uns aber vor, dass wir das nicht auf viel machen. Und ansonsten ist das tatsächlich noch 'n ungelöstes Problem, was sich manuell mit sonem, ich hab sonen Exempelplaner, der mir das parallelisiert. Aber das mache ich dann vor 'nem Release guck ich rein und guck, ist das jetzt eine ungewöhnlich hohe Zahl an Exit Codes, die die nicht 1, die nicht 0 sind. Aber ansonsten schaue ich das einmal durch. Ich krieg 'n Katalog und Chance durch. Das heißt, wir haben da noch nicht Geil wär noch mal sone Ewald Schicht, aber die Komponente haben wir für die 1 0 rausgescopft.
Jan: Aber das heißt, jeweils sind auch was, was ihr euch für das anguckt?
Christopher: Oh, ich hätte ich hätte nicht Bock drauf, ja. Tatsächlich, weil es einfach, also bei den Sachen, die bisher, die wir jetzt im bei in bei der Arbeit gebaut haben oder ansonsten, braucht man braucht es ohne jeweils, also hat hat Max ja auch neulich erzählt in der Folge. Das also ohne geht's eigentlich nicht. Kommt auch meistens in der Folge
Garrelt: zu zu jeweils. Ja. Cool.
Christopher: Ist schon cool in Planung.
Jan: Ich hab übrigens grade geguckt, die Folge hier wird, je nachdem, wie die Folgen da vor sich so verhalten, sagen wir mal Ende Mai, Anfang Juni veröffentlichen. Mhm. Schafft ihr das?
Christopher: Da sind wir ja Hoffen, ja. Ich hab halt so. Es ist immer schwierig, aber ich würde sagen, wir sind dann schon durch mit der 1 0, ja.
Jan: So, ihr habt's jetzt gehört. Hab ich
Christopher: gut gemacht. Haben wir gut gemacht.
Jan: Ja. Ganz kurz auf Pause drücken beim Podcast Player und einmal auf AI Punkt Symphonie ist das, glaube ich, ne, von der Ja,
Christopher: AI Punkt Symphonie Punkt com, ja.
Jan: Ja, einmal nachschauen Oh, das
Christopher: ist ja auch ein.
Jan: 1 zu 0 Precher so. Stimmt. Ja und wenn, oh, für uns jetzt natürlich auch der, ne, wenn jetzt die Folge aus irgend 'nem 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 oder irgendwie die 1
Christopher: 0 Können wir so machen, können wir so machen.
Jan: Mehr timen das ist anders, das
Christopher: können wir schon hin. Ja,
Jan: ist ja auch schön, wenn die Hörerinnen sich das direkt beanspruchen kann. Also unabhängig davon, dass das jetzt bei euch alles in in PHP gebaut ist, worüber wir noch gar nicht gesprochen haben, ob das irgendwie eine gute oder eine schlechte Entscheidung ist, find ich's auf alle Fälle cool, dass ihr für die ganze Architektur, wie Du grad gesagt hast, diese diese Beispiele halt mitliefert, weil unabhängig von von der Sprache so, ne, 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 beim Einstieg so, ne. Von daher Toll.
Christopher: Nice. Das ist so passiert.
Jan: Vor 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 son bisschen daran gelitten, dass es sehr eine sehr hochgradige Abstraktion war und man sehr viel schreiben musste, überhaupt erst mal irgendwas damit zu machen. Also jeder, der mal son Langsharing Projekt irgendwie aufgesetzt hat, Gareth hat zumindest genickt, hast Du wahrscheinlich auch mal angeguckt.
Garrelt: Bitte.
Jan: Der wird ja gesehen haben, okay, bis also bis da wirklich mal was an an Inference passiert oder son Embedding erzeugt ist oder so, da hast Du sehr viele Module zusammengeschraubt irgendwie. Und deswegen auch so meine Frage an dich, Christopher, so wie wie findet ihr so das richtige Level an Abstraktion, zu sagen, okay, damit machen wir es einfacher für die Leute zu benutzen, aber noch nicht zu kompliziert, auch die einfachen in Anführungszeichen Einstiegs Use Cases, ne, nicht unattraktiv zu machen. Weil ich glaub, das ist ja schon das, wie die meisten Leute irgendwie dazu kommen. Die allerwenigsten Leute, vermut ich mal, ne, kannst Du auch gerne gleich das Gegenteil erzählen, aber die allerwenigsten Leute kommen ja an wahrscheinlich und sagen so, ah, ich hab hier schon meine Vektordatenbank und hier habe ich irgendwie mein kleines Model, die Embeddings zu erzeugen. Das einzige, was ich brauche, ist eine Client Library. Dann dann wär alles perfekt und ich könnte sofort loslegen, sondern meistens ist es ja so, ich will irgendwie erst mal 'n Proof of Concept bauen und dann wächst dieses Projekt irgendwie so organisch raus und deshalb glaube ich, so ist es halt wichtig, dass diese diese Einstiegs Use Cases auch gut abgebildet werden können und man nicht erst 50 Seiten Dokumentation lesen muss, irgendwie das 1. Prompt da da loszuschicken. Wie wie wie versucht dir die Hürde da gering zu halten?
Christopher: Das das ist eine ziemlich gute Frage und die ist tatsächlich für mich relativ schwer, weil ich da jetzt irgendwie seit 2 Jahren draufschaue auf das auf die Code Base, ne. Also es ist sehr schwer zu reflektieren. Glaub, das, was mir am Anfang gut geholfen hat, waren grade diese Exampples. Wir haben auch noch mal eine Demo App im, womit man halt dann einfach, ne, inzwischen sehr langweilig zu den ganzen Chat Demos, aber da sind großteils Chat Demos drinnen und auch 'n bisschen was zu Shotshot Output oder Inish 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 rauf gucke und dann noch mal gegen challenge, ist das eigentlich die API, die ich haben will? Und tatsächlich ist das noch 1 der Items, was wir, was Oskar und ich jetzt letzten Freitag auch noch mal besprochen haben, dass uns das mit dem Agent Interface so noch nicht ganz passt. Weil tatsächlich gibt's ja auch einfach son bisschen Erosion über jetzt 2 Jahre, wo man dann merkt, gut, am Anfang war das vielleicht wichtig und richtig so. Aber inzwischen gibt's vielleicht so was wie, die sind ja beim Agent was sehr, sehr hochwertiges vom vom vom Contract her. Und bisher war das dann immer so, dass man das als erstes in die Messageback vom Kontext gepackt hat. Und eigentlich würd ich gern differenzieren, auch im im Interface so. Das heißt, ich ich würd sagen, es ist 'n wiederkehrendes Reflektieren auf diesen diesen Exempel, zum Beispielcode, was mir zumindest hilft. Und das andere ist, wir haben, ich hab jetzt 'n paar Workshops gegeben, auch bei der SymphonyCon oder Symphony online, wo ich dann wirklich direkt mit Leuten zusammen Übung mache und dann auch sehe quasi, was irritiert die Leute? Was hilft ihnen? Und ich glaub, das ist das ist son bisschen das, was ich hoffe. Aber es ist schwer zu schwer zu objektivieren dann, glaube ich.
Jan: Das, was Du grade angesprochen hast mit, ne, mit mit Schotter sehr lange drauf und dann gibt's vielleicht son paar Sachen, die man wieder wieder anders machen würde. Da baut vielleicht mein nächster Punkt son bisschen drauf auf. Diese ganze AI Welt dreht sich ja unglaublich schnell, so. Fast so schnell wie das JavaScript Framework Ecosystem, so. Ich nicht, was was schneller entsteht. Neue Modelle oder neue Javascapeworks, aber so ungefähr ist so die Moment
Christopher: sind die Agent Protokolle, glaube ich. So die Agent Protokolle sind ja irgendwie, ich weiß nicht, wie viel gibt's inzwischen.
Jan: Ja und wie wie fühlt sich das dann für euch so als Maintainer an, da also das ist ja son Katz- und-Mausspiel eigentlich, ja, weil es es kommt, ne, neues Agent Protokoll raus oder 'n ganz neuer irgendwie architektonischer Ansatz. Jetzt gibt's irgendwie, weiß nicht, MPC ist auch schon 'n 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 Agent2 Agent und dann ruft vielleicht dein Agent irgendwie Sub Agents auf und so weiter und so fort. Und ich weiß nicht, also wenn wenn Du morgens so den Rechner aufmachst, wie viel Angst ist da so dabei, dass irgendwas Neues jetzt irgendwie grade rausgekommen ist, dass ihr jetzt auch noch unterstützen müsst oder ist das überhaupt gar kein Problem für euch, weil ihr sagt, na ja, Scoop ist fertig, Future Set ist final und alles andere machen wir jetzt erst mal nicht?
Christopher: Na ja, das das müsste ich jetzt, glaube ich, so auf 2 Ebenen, weil es ist für mich auch das 1. Mal, dass ich son 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 dieses dieses diese Notification Bubble auf GitHub. Allein das ist ja schon was, was einen stressen kann. Und dann hast Du noch die Leute, die halt anderer Meinung sind und da musst Du mir ja auch immer überlegen, ob die jetzt recht haben oder ich selber. Und dann kommen natürlich noch diese 5 Newsletter dazu, die man abonniert hat und dann die E-Mail-Postfach landen und dann einmal erzählen, was da jetzt alles macht. Das ist schon ist schon ist schon real. Also das das das spüre ich, sag ich mal. Aber ich hab auch gemerkt, dass sone gewisse Trägheit schon auch hilft. So, ich habe so eine gewisse Trägheit entwickelt, nicht bei allem jetzt immer direkt zu denken, okay, wie bauen wir das jetzt ein, sondern erst mal abzuwarten, ob's dann ob's dann irgendwie nach 2, 4 Wochen auch noch irgendwie dann wieder 'n Issue ist dazu. Weil ich sag mal so, Sub Agents als Tastenbasketball wurde haben wir das gelöst, indem wir Agent Tool einfach umbenannt haben, ne. Also das war schon vorher da, aber war halt einfach konzeptionell. Und ich würd sagen, tatsächlich konzeptionell haben wir sehr viel von dem Teil ist wirklich so Abstraktionspettern und Seralisierungsspettern und dann die 2 Ideen, auf der die Plattform steht, ist halt einfach Tool Calling und Structured Output. Da ist nicht viel passiert in den letzten 2 Jahren, so doof das klingt, ne. Und ich ich ich glaub, der Rest ist sehr viel Ich würde gern mehr Richtung Gen UI gehen, so. Das ist tatsächlich was, was ich noch nicht so geknackt hab, wie wir das angehen. Das ist son Buzzword, was was auf jeden Fall noch, ob das jetzt a2 I, a gUI oder was, das weiß ich nicht so, aber oder MCP Apps, aber das das ist, glaube ich, so das Nächste, was ich mir langfristig anschaue. Weil ich versuche jetzt wirklich zu filtern, ja.
Jan: Ja. Das ist so das Problem aus deiner Perspektive, ne, aus aus eurer Maintender Perspektive. Dasselbe gibt es ja aber auch aus Development Schrägstrich Library Anwender Perspektive, ne. Wenn ich mir jetzt das Library angucke, muss ich ja für mich auch sone Abwägung treffen und sage so, okay, will ich will ich quasi das Library nutzen und damit so gefühlt den Trade off eingehen, dass ich vielleicht 'n halben Schritt hinterher bin und ne jetzt nicht GenUI gleich nutzen kann oder warten muss, bis Sub Agents unterstützt, Schrägstrich umbenannt wurden. Stimmt. Sowas, ja. Wie wie nehmt ihr das wahr? Auf wie viel Gegenliebe oder Akzeptanz stößt da son Library oder wie viel Angst haben die Leute, dass sie vielleicht irgendwas verpassen könnten, wenn sie auf sone Abstraktion
Christopher: setzen? Ich glaube, dass, also wir haben 'n paar Learnings da schon durch, ne. Am Anfang war das so, dass wir zum Beispiel, klingt jetzt im Nachhinein total banal, so, wir haben die Modelnamen. Wir haben gedacht, es ist cool, wenn ich einfach eine Konstante habe für GPT-4. So, dann kann ich das direkt mit Auto Completion habe ich's da und kann's nutzen. Ist aber so vom von den Change Szenarien, ich will ja meine updaten updaten updaten, nur weil da 'n neues Model released wurde. So, ne, sowas, das das ist ganz klar son Fehler gewesen. Und generell haben wir an vielen Stellen durch durch, sag ich mal, Decoration Pattern und Interfaces die Möglichkeit. Du kannst dich relativ viel raufsetzen auf Sachen, die wir gebaut haben, ob's jetzt die Toolbox ist, ob es der der der ist, den wir haben. Das heißt, ich ich würde das erst mal ganz defensiv beantworten mit den Extension Points, die wir haben, so. Und das Einzige, was wir da tatsächlich noch wirklich als Schmerzpunkt haben, ist ist Streaming. Also Streaming funktioniert, aber es ist tatsächlich dich in, also diesen Generator, den wir da gebaut haben, der halt sozusagen ausm HTP Layer bis in den DTO Layer die einzelnen Deltas hochjildert, dich da irgendwie entspannt reinzuhängen für deine eigenen Extension Point, das noch 'n bisschen, muss man schon genau wollen, sag ich mal.
Jan: Und ganz kurz bei den Development zu bleiben, was glaubst Du oder weißt Du vielleicht sogar, ist der der größte Selling Point für das Library am Ende des Tages? Ist das so dieses, boah, ich bekomm halt viel Abstraktion, Interfaces und DTOs irgendwie aus 1 Hand und muss mir das alles irgendwie nicht mehr Gedanken machen, sondern kann direkt anfangen, was zu bauen und das zu nutzen? Oder ist es eher dieser Punkt, na ja, wenn ich darauf aufbaue, ist es relativ einfach für mich am Ende von, weiß nicht, ChatGPT oder GPT 5 auf Gemini, auf ne x-beliebiges anderes Model zu wechseln, weil da hätte ich auch noch eine kritische Frage zu. Aber erst mal vielleicht so, warum kommen die Leute überhaupt?
Christopher: Ich glaub, das eine ist son bisschen der Stack an sich, weil Du kannst relativ easy, wenn Du in eine PHP App schon hast, jetzt dieses Feature, also diese Featurewelt aufmachen. Und das ist grade, wenn's Toolcalling geht, ist das schon ziemlich verlockend, einfach zu sagen, okay, ich hab 'n Agent, der kann jetzt auf in meinem in meinem Servicekontext einfach zugreifen. So, und das heißt, wenn Du Bestandsanwendungen hast, auch grade mal größere, ist das einfach, glaub ich, ganz gut. Ich find tatsächlich, und so hab ich die Workshop auch meistens angefangen, einfach mitm HTTP klein anfangen, Dinge zu verstehen. Das heißt, einfach nur direkt die installieren und dann irgendwie Agent macht schon irgendwelche Dinge. Das würde ich gar nicht empfehlen als Staat so, sondern ich schon schon sagen, die HTC APIs mal auszuprobieren vorher muss nicht Cur sein, aber irgendwie son HTC Client oder Gasse, das ist, glaub ich, fürs Verständnis ganz cool. Ansonsten würde ich sagen, ist der größte Selling Point tatsächlich, dass Du dich nicht so Grundlagendinge kümmern musst, ne.
Jan: Weil was das, also was ich immer son bisschen hinterfrage bei diesem ganzen, ne, es gibt ja einen einen Adapter 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, so, ne, 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, weiterrauten an OpenAI, Antropic, Germany, was auch immer.
Garrelt: Sowas wie Open Roter?
Jan: Sowas wie Open Roter, ne. Ja, ja. Und ich
Garrelt: frag mich halt, wie
Christopher: real dieses Versprechen wirklich
Jan: ist, weil ich mir,
Christopher: wenn ich
Jan: mir jetzt vorstelle, ich bau eine eine Anwendung und ich teste und entwickle die jetzt gegen, sagen wir mal, GPT5. 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, so, ja. Dann kann ich ja gefühlt meine halbe Businesslogik mit rauswerfen, weil ich muss ja das ganze prompt, also gefühlt muss ich ja viel von dem Prompt neu schreiben. Alles, was ich fein gehütet hab, alles was ich getestet hab, das ein anderes Modell verhält sich ja komplett anders. Und ich frag mich in dem Moment, wo halt viel von dieser Businesslogik so nicht deterministisch wird, wie praktikabel das überhaupt ist, mein halbes LLM unten drunter auszutauschen, ja. Das kommt bestimmt auf den Use Case an, ne. Wenn ich mir unser unser Translation Tool hier anschaue, was Benny bei uns intern gebaut hat, die ganzen Spiele zu übersetzen und sowas. Das wär glaube ich machbar mit vielen anderen Modellen auch. Also ich glaub, Sie haben's ja auch mit verschiedenen Modellen getestet. Wenn ich mir jetzt aber so was überleg wie unser unser dieses Buchhaltungssystem, das Bände, was wir da nutzen, was da so deine Rechnungen durchscannt, ne und ihr dann so findet, hey, was ist dein Steuerbetrag, was ist dein Rechnungsbetrag, wer ist dein Rechnungsstellerblau 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 dir noch genauso passende Ergebnisse liefern.
Garrelt: Ich weiß auch gar nicht, ob das wirklich das Szenario ist, was was ich mir vorstelle, weil ich hab das Gefühl so, wenn Du eine Businesslogge 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, irgendwie schon, für mich zumindest. Also, ja.
Jan: Wir haben das hier nicht so viel, sonst musst Du wissen.
Christopher: Macht's auch einfach.
Garrelt: Ja, ja. Und selbst weißt Du, selbst wenn Du dann mal wirklich den Moment hast, wo die abhängig irgendwie teurer geworden ist, dann kannst Du halt relativ einfach wieder gucken, okay, welches Model klappt denn trotzdem noch gut mit dem, was ich hab, so.
Jan: Ich glaub, Du hast natürlich recht. Ich glaube, wirklich wollen tut man das Model nie wirklich tauschen, aber wir haben das ja jetzt auch schon in den letzten paar Jahren gesehen, die werden halt auch der Location abgeschaltet irgendwann.
Christopher: Ja. Ja.
Jan: Ja. Und manchmal tatsächlich auch relativ schnell. Ja, ja.
Christopher: Ist ja auch son Punkt. Ich ich glaub, der wichtige Teil ist einfach, dass man die Möglichkeit erst mal hat, das so zu bauen, dass man an 1 zentralen Stelle das also und und selbst, wenn Du's da noch hardcorest, das muss ja nicht mehr unbedingt dann irgendwie in 'ner in 'ner Konfiguration sein. Was ich tatsächlich jetzt auch grade von dem von der Produktwelt, in der ich so unterwegs bin, ganz, ganz spannend finde als d, ist halt oft wirklich dann Proms 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, sodass die sagen, ja, ich hab jetzt das das Opus benutzt und und manchmal entsteht son son Consumer Mastery Feeling dabei, ne, weil ich hab jetzt mal das ausprobiert. Ich hab mal das ausprobiert. Und wenn Du halt eine Anwendung baust, wo Du dann in dem Administrationssettings auch noch mal switchen kannst zwischen unterschiedlichen Dingen und der Anwendungscode ist davon halt einfach 'n bisschen entkoppelt. Und Du kannst vielleicht sogar auch Proms zur Verfügung stellen. Dann dann ist das eine Infrastruktur, die bis zu 20 5 Minuten AI dir einfach bietet direkt.
Jan: Ja, das ist wahrscheinlich auch 'n cooles Argument, grade auch in diesen ganzen Bring your own key Szenarien oder so was, ja, wo Du halt sagen kannst, meine Anwendung erfordert halt 'n LLM, Du kannst 'n Key mitbringen von, Germany, Open AI, whatever. Und wir nutzen dann halt einfach was, was möglich ist sozusagen. Mhm.
Garrelt: Ja, das da hab ich nicht drüber nachgedacht, ja.
Christopher: Ja, die Alternative ist, wir wir wollen ja als wir wollen das Symphony AI auch so bauen, dass wir uns nicht auf irgendeinen Provider einloggen. Das heißt, wir haben, wenn wir sagen, wir wollen in Symphony irgendwelche AI Features schippen, haben wir gar keine andere Wahl. Wir wollen ja nicht Symphony AI powered by Open AI bauen. So, das ist halt, geht halt nicht. Find ich auch nicht.
Garrelt: Sind lokale Modelle 'n Thema bei euch, also die auch im Web, in der Web Run Time laufen?
Christopher: In der also in der kleinen Run Time des Browsers?
Garrelt: Ja, ja, genau, ja.
Christopher: Ich würde gerne. Ich weiß nur noch nicht genau, wie. Also ich fänd's tatsächlich geil, irgendwie da sich sich quer durch durchs Auge quasi da die die aus dem Browser rauszuholen. Aber ich ehrlich gesagt, selbst wenn wir das irgendwie zusammenbauen, glaube ich nicht, dass das 'n cooler Use Case ist für eine Server Site Language So. Also was was wir halt, was wir halt zur Verfügung stellen, ist, Olama Bridge, LM Studio, Docker Model Runner, diese diese Klassiker. Und das, was son bisschen, da komme ich vielleicht noch mal zu diesem PHP Punkt. Das, 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-G- Bereich. Und dann kannst Du wirklich in der PHP Runtime auch Model Inference machen.
Jan: Das kannte ich gar nicht. Was wird da was wird da angesprochen am Ende in C? Ist das dann so Lamals oder was?
Christopher: Also One NYX.
Garrelt: Ja. Ja. Mhm.
Christopher: So das von von Kiran eine ziemlich abgefahrene Library, die jetzt dann durch dieses Interface C-Binex dann aufbaut. Frag mich nicht genau, wie das funktioniert.
Garrelt: Schade. Da also, ich find ich find cool, dass
Jan: so was geht. Ich frag mich, ob das sinnvoll ist, weil das also weil das 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.
Garrelt: Mhm.
Jan: Und mit Network Requests, so hoffe ich jetzt die natürlich sind, aber hab ich halt den Vorteil, dass das entkoppeln kann. Also wenn jetzt meine Anwendung irgendwo in meinem Cubanetes 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.
Christopher: Ich find, das zitieren sich denn aus. Also Du Ist auf jeden Fall 'n total valide Punkt, so. Das macht's echt schwieriger. Vor allen Dingen, ich ich würde auch gar nicht in dieses Game reinholen, in Phoenix zu scalen. Das wär mir viel zu viel zu krass. Aber ich würd noch mal als ein Argument, was ich hätte, wäre, dass ich sowieso versuche, wenn wenn's geht, die die Abhängigkeit in irgend einen asynchron Prozess zu verlagern, dass es in 'nem Worker ist. Und dann könntest Du auch überlegen, ob Du da 'n PHP Worker hast, der heult auf irgend 'ner Maschine läuft die halt
Garrelt: Richtig, ja.
Christopher: So was eben Zweifel könnte. Mhm. Trotzdem tatsächlich nix, was ich bisher nach Production gebracht hab. Und das seh ich auch grad nicht in meiner nahen Zukunft. Aber Du
Jan: sprichst 'n 'n guten Punkt an mit der mit der Langläufigkeit. Das ist ja jetzt auch keine klassische Stärke von PHP, es mal neutral zu gehen
Christopher: bezogen auf PartTP oder bezogen auf Seal Eye Prozesse generell.
Jan: Genau, nein, Seal Eye Prozesse generell, weil Du grade den Worker ansprachst, der das dann vielleicht abarbeiten muss auf dem auf dem Node. Und ich weiß, dass es da mittlerweile viel Bewegung in dem Space gibt, aber ich glaub, viele von den Zuhörern wissen es so nicht, deswegen lass uns da vielleicht einmal kurz drüber sprechen. Wie problematisch ist es denn aktuell überhaupt noch so PHP langläufig zu betreiben? Und was muss so euer dafür noch explizit tun, das halt besser zu unterstützen? Ich weiß nicht, sind sind Memoryleaks ein Problem, so. Ja, ich mein, irgendwo auf der Webseite hab ich gelesen, so, so das Doktrin von Doktrin für LLMs werden so ungefähr, ja. Doktrin so als Datenbankabsauktionen früher, weil grade so mich schon fragend anguckt. Und Doktrin war ja auch dafür bekannt, irgendwie Memory zu liken links und rechts. Oh. Ja. Deswegen so meine Frage, wie wie viel Sorge muss man noch Langläufigkeit machen?
Christopher: Also prinzipiell ist das auch in meiner Erfahrung so, dass dass je länger 'n PP Prozess läuft, desto ineffizienter wird er. So, das das Ich weiß auch nicht, ob ich das jetzt noch eingespeichert hab von vor 10 Jahren, aber das das, was was Du beim Simp die Messenger hast und das ist das die Komponente, die ich einsetzt dann für asynchron. Ich kann direkt mitgeben, wie lang die vielen Messages verarbeitet werden, bis der Prozess durchgestartet wird. Das heißt, Du hast immer eine, diefolmäßig, glaub ich, setzt, die gibt's in der in der Dokumentation gibt's 'n Beispiel dann Physsuppvisor die. Und das Ding killt sich einfach selber nach 10 Messages, nach 'ner Stunde, nach 10 Minuten, wie Du's konfigurierst. Das heißt, letztlich wär das dann ganz elegant Richtung die Verlopper landgeschiftetd das Problem, dass Du rausfinden musst, was dein dein gebautes, dein gebauter Worker sozusagen ab verträgt. Ich hab tatsächlich, mir ist jetzt grade überhaupt nicht bewusst, ob wir irgendwelche Memory Leaks in Workern haben oder so was, wenn man das länger läuft, ist mir, glaube ich tatsächlich nicht, ehrlich gesagt, dass wir dass wir das Problem haben im Moment. Und der Vorteil im Messenger ist halt tatsächlich auch, dass Du ganz explizit über son Resetable Interface, heißt es, quasi zwischen den Messages Dinge freigeben kannst. Wenn Du sauber baust, das heißt, das ist auch wieder geschiftet das Problem.
Jan: Wobei man wahrscheinlich ja auch sagen muss, die Langläufigkeit im im Umgang mit AI besteht ja wahrscheinlich zu 'nem sehr großen Teil einfach aus Warten auf das LLM. Das ist ja nicht so, dass da so viel Heavy Lifting gemacht wird, wie wenn ihr jetzt, weiß ich nicht, Videotranskoding betreiben würdet da irgendwie am Stück oder so was, sondern da ist ja viel iOS wahrscheinlich was passiert einfach, oder?
Christopher: Ja, ja. Und ich ich würd tatsächlich sagen, das ist auch immer noch relativ valider Kritikpunkt, wenn man wenn man so auf Parallelisierung hinaus will. Es gibt definitiv Lösungen, wie wir grade auch dann mit oder oder oder Dinge ganz gut parallelisieren können, sodass Du auch keinen, dass Du asynchron arbeiten kannst. Dadurch, dass die Sprache selber jetzt nicht oder macht, sind es immer Lösungen, die sozusagen setzen. So, es geht auf jeden Fall und ich hoffe, dass diese dieser RFC für das True Usnc irgendwann mal durchkommt und die Sprache das dann auch selber kann, aber das ist jetzt Opinion.
Jan: Das ist okay, dafür sind wir da so, ja? Stimmt. Wenn wir hier keine Meinung hätten, könnten wir auch Doku vorlesen gegenseitig, ne. Also wir wir sind ja auch an Menschen und Meinungen interessiert, von daher, ah, alles alles gut. Ja, ich geh grad so mein Fragenkatalog hier durch. Garalt, hast Du noch eine Frage?
Garrelt: Ja, ich hatte eine, die son 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. Also wie Das ist das royale Wir. Wie haben sich das? Am Liebsten. Ah ja, das wär das wär so geil. Glaube ich's 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?
Christopher: Ich hab tatsächlich angefangen, irgendwann in 'nem separat Projekt erst mal LLM Chain hieß es. PHP LLM war so die Orgel dazu, angefangen. Und dann relativ bald ist Oscar, Oscarstark auch ausm Symphonieor Team da mit gesprungen. Mhm. Und ab da würde ich sagen, es ist ein Wir, ein also wirklich grammatikalisch und nicht Majestät. Und dann tatsächlich hatten wir irgendwie plötzlich Leute, die halt wirklich aus Finnland oder wirklich round the Globe angefangen haben zu contributen.
Jan: Und dann haben wir
Christopher: gesagt, okay, irgendwie macht das macht das Spaß und macht das Sinn. Und dann haben wir Ich glaub, Oscar saß in 'nem Flieger mit Fabienne nach 'nem nach 'nem Hackday oder irgend 'nem Symphany Day in den Staaten. Und dann haben die gequatscht und dann haben wir im März letzten Jahres beschlossen, so, machen wir doch aus dem PHP LLM machen wir mal Symphany Real. Mhm. Das Ich hätte tatsächlich Oh, ich weiß gar nicht, das wird wird hier noch aufgezeichnet, aber ich hätte tatsächlich gerne noch 'n bisschen gewartet, das da unter dem Branding auch zu publishen. Mhm. Weil in dem Moment Also Du kannst dich ja entscheiden, willst es partizipativ auf 'ner offenen Bühne bauen? Oder willst Du irgendwann bei 'ner Konferenz den Vorhang fallen lassen und sagen, das ist es?
Jan: Mhm. So,
Christopher: das sind 2 unterschiedliche Ansätze, ne. Und auch, ich glaub, Laravell hat sich son bisschen zu dem anderen Ansatz entschieden. Wir haben dann im Juli letzten Jahres gesagt, okay, hey, wir wollen das bauen. Symphony AI, wer ist mit dabei? So. Und dann muss ich erst
Jan: Aber grade dafür kann ja das Symphony Branding auch hilfreich sein, ja, weil Voll. Natürlich da schon sone größere Bubble irgendwie mitkommt, anstatt wenn also nichts gegen dich, ja, aber es macht wahrscheinlich den Unterschied, wenn Du dich irgendwie ins Internet stellst und 'n bisschen trommelst und sagst so, hey Leute, lass das irgendwie alle machen oder wenn Fabienne auf der großen Fünften Bühne steht und sagt so, ihr habt alle Bock auf, ey, dann helft ihr jetzt dem Christopher, go.
Christopher: Genau, aber das das war ja genauso, ne. Also das dann auch, als das Monorepo dann aufgebaut war, dass es dann nach hieß, okay, dann lass uns möglichst schnell public machen. Und ist auch egal, wenn da jetzt erst mal kein Tech dran ist, sondern einfach nur, dass Leute Bescheid wissen und die Bock drauf haben können mitmachen. Und jetzt sind wir, glaub ich, bei über 120 Contribodern oder sagen wir, über 100. Ja, knapp an den 2000 Pool Requests. Das heißt ordentlich ordentlich Lärm.
Garrelt: 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?
Christopher: Gute Frage. Ich glaube tatsächlich, dass die V1 wäre früher da gewesen, weil
Jan: Und die Breite keine Antwort auf die Qualität war, was er würde Genau. Obwohl auf den Prozess war.
Christopher: Ja, ja, genau. Ich ich glaube, unterm Strich ist es jetzt besser, weil es 'n gewissen Findungsprozess dabei hat. Ich glaube aber auch tatsächlich, dass wir jetzt in den letzten Wochen schon wieder was weggeschmissen haben, also bald jetzt. Mhm. Und und wieder son bisschen mehr aufn Fokus kommen. Aber das ist halt 'n Lernprozess dann vielleicht auch als Community dann. Und ich glaube, das ist grade für PHP in diesem AI Game schon wichtig, dass das wirklich auch Community erfolgt ist und nicht nur 2, 3 Leute.
Garrelt: Ja, Cool.
Jan: Du hast deine 120 oder 100 Co Contributers angesprochen. Wie viele davon sind denn Cloud Code oder so? Also die die die Frage ist, wie viel AI steckt in Symphony AI drin und wie viel Handarbeit ist das so? Wie wie sieht so dein Entwickleralltag damit aus?
Christopher: Ich würde sagen, tatsächlich, dass 90 Prozent des Codes, den ich heute schreibe, nicht nicht ich bin so, sondern halt ist, Pi 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 2 Jahre, das hat sich ja schon auch deutlich geändert. Es ist aber trotzdem so, dass und das da kommen wir wieder zu dem Punkt von vorhin, ne, wo dieses was ist jetzt das, was wir shippen und was ist eigentlich 'n Extension Punkt, weil ich dann schon auch irgendwann an dem Punkt war, wo ich hätte, okay, jetzt hab ich das hier hab ich einfach nur gepompttet. Das hat mich eine halbe Stunde gekostet, das noch mal schick zu machen. Ist das wirklich 'n Feature oder ist das was, was jeder da selber rantackern kann?
Jan: Mhm.
Christopher: So. Super. Und und und deshalb, ich glaube, die Sachen, die da jetzt drin sind, sind schon deutlich komplexer oder deutlich mehr als das, was was wir Also jetzt haben wir Skills drum herum, die dann irgendwie Doku noch mal glatt ziehen. Oder wenn wenn wir jetzt irgendwie, wir haben in den 20 Backdoor Bridges haben wir eine Methode nachgezogen. Und dann haben wir gesagt, okay, das können wir erst mal über Agents parallelisieren und solche Sachen. Das das passiert schon, aber ich würde schon sagen, gerade rund die Refactorings beim Stream, bei den Contracts und so was, das ist schon doch noch sehr viel zumindest selber nachgedacht vom Prompton.
Jan: Mhm. Das ist ja schon mal was. Also nicht alle da draußen die Prompton?
Christopher: Nee, aber wenn, ich weiß, dass es auch Kritik gab, dass ich an anderen, wo man sagt, okay, das ist Bild alles sehr. Das würde mich tatsächlich schon treffen, wenn das jetzt das Assessment wäre von Snof Nier, weil das ist zumindest für den Teil, den ich beigebracht hab, nicht nicht nur Vibe, sondern auch Planung und Prompton.
Garrelt: Schön, schön. Gabriel, letzte Frage. Letzte Frage. Jetzt son bisschen sone Metafrage, Lust auf eine Metafrage. Was hast Du, sagen wir mal, über Eye gelernt, als Du diese Leihbudget geschrieben hast? Was da gab's irgendwas, wo Du Kleine Frage zum Schluss. Die kann man vielleicht auch leicht beantworten. Willkommen bin
Jan: ja dann
Garrelt: mit einem
Jan: da zu diesem Podcast.
Christopher: Ist eher nicht technisch, würde ich sagen, tatsächlich. Also dieses Transformation, durch die wir 3 hier laufen und die die zuhören, das schon nicht ohne. Das ist tatsächlich aber eine eine emotionale Sache, glaube ich. Also das, was ich gelernt habe, ist, dass dass hoffentlich Programmieren nicht mein Key Skill ist, weil das ist nicht mehr so relevant.
Garrelt: Mhm. Das sag ich auch immer.
Christopher: Ja, es ist hart. Aber ich ich bin an dem Punkt. Es gibt diesen einen diesen einen Blogartikel über die und ich ich bin ich befinde zwischen der Depression und der fünften Phase, der der Dass man das überwunden hat, aber ich glaube, es ist tatsächlich das, was ich Wenn Du mich dann erfährst, würde ich sagen, das habe ich gelernt, ja.
Garrelt: Mhm. Und das Also das part, gerade die Library Entwicklung oder das Beschäftigen mit diesem intensiven IT Thema, so bei dir Ja, genau.
Christopher: Also es ist wirklich eher dann der der der Zeitpunkt des Bauens, ja.
Garrelt: Ja, ich glaub, so wird's so wird's auf jeden Fall irgendwann uns allen gehen, würde ich sagen. Wahrscheinlich sind noch nicht alle da, aber
Jan: Ich glaub, 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 das Code in die Tasten tippen halt nur das Endresultat 1 sehr viel längeren vorgelagerten Prozesses ist, das wird halt sehr oft übersehen und dann, ne, wie halt Christopher auch grade meinte so, da kommt dann halt die Erkenntnis, dass das das ja gar nicht ist, aber auch da muss man erst mal hinkommen.
Garrelt: Ich antworte da jetzt nicht drauf, weil sonst haben wir wirklich die nächste Stunde den Podcast angepasst.
Jan: Vorbereitet. Hören Sie dir Fortsetzungen 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?
Christopher: Eigentlich die eine kettee Frage, warum machst Du das in PHP? Die die hätte ich erwartet. So, da waren wir 'n bisschen, dann wird dran dran haben wir dran gestrichen so und ich glaube, eigentlich haben wir das Thema auch behandelt. Aber das ist sone Frage, die ich die ich die ich schon höre manchmal. Mhm.
Jan: Und was außer 20 Jahre Hingabe ist deine Antwort auf diese Frage?
Christopher: Die HTTP APIs sind doch schon mal son Level, dass Du gar keine Technologieentscheidung mehr machen musst sozusagen, ne. Also warum warum, also das HTTP Player ist ja da. Also das kannst Du aus dir. Du kannst auch das mit Curle und Bash bauen, wenn Du willst. Also klar und die Integration mit Bestandsanwendung, so. Klar.
Jan: Ich seh grade irgendjemanden zu Hause sitzen, der seinen, weiß ich nicht, Cloudcode jetzt grade prompttet, bau mir 'n AI Agent in Curle und Bash. Und es wird wahrscheinlich funktionieren. Wirklich instabil und schlecht, aber es wird funktionieren.
Garrelt: Wobei, also meine Antwort auf die Frage, wie viel Prozent des Internets läuft immer noch mit PHP? Also ich mein,
Christopher: bummelig irgendwie
Jan: Alles, was wichtig ist.
Garrelt: Wie viel,
Christopher: 70? Irgendwas, ich glaub 75, 73, 7 77. Ja. Man muss auch dazusagen, dass 43 Prozent davon WordPress ist, ne. Und an Okay, okay. Also das Man sagt das immer gerne, 77 Prozent des PHP, aber davon ist sehr viel WordPress, was auch PHPs.
Jan: Das Ich ich weiß gar nicht, ich mein, das hatten wir in der PHP Folge auch schon son bisschen hin- und her philosophiert, ne?
Christopher: Aber ich glaub einfach auch,
Jan: es sind ja also ein paar sehr große Player, die noch einfach PHP machen. Allein wenn Du überlegst, wie viel Anteil an Webtrafic Wikipedia alleine wahrscheinlich hat oder so was, ja, da geht viel hin. Ich hab ich warte immer noch darauf, dass hier jemand anruft und mir uns eine Folge machen will, wie viel PHP grade noch bei Facebook irgendwie läuft, weil die ja auch sehr große Anwender sind Schrägstrich waren. Die haben irgendwann aufgehört darüber zu reden, das ist jetzt son kleines Fragezeichen dran, aber die waren auch irgendwie immer ganz groß und so. Man guckt halt nicht
Garrelt: so drauf. Man hat's nicht mehr so aufm Schirm irgendwie. Ja.
Christopher: Na, aber ich glaub, grade im im E-Commerce-Bereich und und CMS Bereich, grade CMS und Gen AI macht schon auch einfach erst mal Sinn, so Ah, ja. Und das das passt schon, glaube ich. Cool, cool.
Jan: Dann wären wir ja im Prinzip schon fast durch, oder Gerald?
Garrelt: Ja, aber es kommen noch die. So ist das, hast Du das richtig gesagt? Nein, wir
Jan: sagen das richtig. Okay. Wir sagen das nicht. Ich glaub Fabi sagt das immer falsch, gell?
Garrelt: Was seid ihr denn?
Jan: Wir bleiben jetzt hier einfach mal Fabi. Fabi sagt immer Pick of the Days und das ist ja
Garrelt: Nee, Pick of the day. So
Christopher: ist das.
Jan: Aber es
Garrelt: heißt ja auf besser, Pick of the
Jan: day. Gefühlt wenn ich diese Folgen höre, ist dieser Jingle ultraschnell. Jedes Mal, wenn ich da sitzt und warte, bis er durchgelaufen ist, kommt er mir unglaublich lange vor. Okay. So, Garalt, hast Du die letzten 60 Minuten genutzt, deine Hausaufgaben zu machen?
Garrelt: Natürlich. Dann darfst Du anfangen. Ich bitte, was was Du auch gut schon erwähnt hast, Christopher, und zwar einen Newsletter, den einen von den 5, die ich habe, die ich momentan lese, die ich nämlich sehr cool finde und zwar aus dem Grund, den habe ich abonniert zu 'ner Zeit, wo ich in dieser Depressionsphase war, würde ich sagen, was so er hingeht. Und dieser Newsletter hat da es geschafft, wieder für mich 'n sehr viel positiveres Licht drauf zu werfen so, weil das einfach irgendwie insgesamt positiv auf diese Dinge schaut, aber auch so sehr emotional und persönlich geschrieben ist. Und zwar ist das der Newsletter von, und ich sag den Namen immer falsch, Thorsten Ball. Thorsten Ball ist, soweit ich weiß oder war ein Entwickler von Amp und Du musst, glaube
Jan: ich, kurz erklären, was Amp ist.
Garrelt: Ja, ich weiß es selber nicht so ganz genau, ehrlich gesagt. Also es hat es ist halt auf jeden Fall auch was mit AI Agens zu tun. Yes? Wenn Du es weißt, dann sag Du es bitte.
Jan: Also ich hätte Amp einfach abgespeichert als so Coding Agent.
Garrelt: Ja, hab ich auch, aber es war mindestens nicht so schlimm. Ich mach das ja. Ja, das ich dachte schon, Amp Code. Ja, okay, es sieht aus wie ein Cloudcode für Coole.
Jan: Ich stehe übrigens bei m, stehe ich glaube ich seit, ich will nicht lügen, aber 3 oder 4 Monaten mindestens auf der Warteliste und ich krieg ab und zu sone E-Mail mit, hey unsere Warteliste ist voll voll und übrigens, deine E-Mail-Adresse sieht gar nicht echt aus, also bitte. Kannst Du dich bitte noch mal bewerben? Also,
Garrelt: oh was? Es gibt eine Warteliste? Okay. Ja. Ja, auf jedenfalls für
Jan: den, sorry, die Warteliste ist nur für den kostenlosen Access von Apple. Du bezahlen willst, die stehen auch in der E-Mail. Wenn Du bezahlen willst, kannst Du sofort irgendwie loslegen.
Garrelt: Moment, aber hier kann man einfach, das kann man einfach installieren.
Jan: Ja, und dann brauchst Du 'n Account. So, Cloud Code kannst Du auch einfach installieren, hilft dir nun nix.
Garrelt: Auf jeden Fall dieser Newsletter heißt Joy on 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 er gelesen, was hat er miterlebt und so und dann immer seine Brille darauf. Und man bekommt schon immer ganz gutes Gefühl so, worum's 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 'n Engineer und er ist sehr so engineer positiv, sag ich mal, was die RAWELT angeht und mir tut es gut.
Jan: Aber ist er ist er positiv, so wie wir das hier manchmal sind oder ist er son Fanboy wie Dennis?
Garrelt: 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.
Jan: Nehmen wir mit.
Garrelt: Nehmen wir mit.
Jan: Christopher, was hast Du so am Start?
Christopher: Ich hab tatsächlich 'n Buch. Ich weiß gar nicht, ob das hier mit Video ist oder nicht. Das heißt Sketch Notes in der IT.
Jan: Oh ja, nice.
Christopher: Und das ist tatsächlich für die Leute, die Also grade jetzt, wenn man auch noch mit Menschen zusammenarbeitet, ist das Visualisieren von Software Architektur gerade superhilfreich.
Jan: Habt ihr alle gehört, wie Christopher gesagt hat, wenn ihr noch mit Menschen zusammenarbeitet? Ja. Du hast, ne? Kleines Wort leistet sehr viel in diesem Satz, ja.
Christopher: Ja. Aber deshalb trotzdem, deshalb finde ich das als Kontrast sehr wichtig, ne? Also Visualisierung, das ist von Lisa Maria Moritz. Ich glaub Schäfer heutzutage. Und das ist gerade, wenn man dann selber noch irgendwie 3 linke Hände hat beim in Miro oder Excalidore oder was auch immer, ist das eine sehr gute Step by Step Anleitung, wie man manchmal dann Dinge Also wirklich in dem Buch wird es wirklich für Leute wie mich erklärt, wie man wie man Dinge visualisieren kann. Und das ist tatsächlich sehr hilfreich für uns, würd ich sagen.
Jan: Ich hab sie mal Jungs
Christopher: als Industrie, nicht mich als Plural, ne. Also
Jan: Ich hab's immer darüber sprechen sehen und ich muss immer sagen, ich find Leute, die auch so auf Konferenzen von Sessions oder sowas, ne, die ordentliche Sketch Notes mitschreiben können so so live, Nee, ja. Das ist ein abgefahrenes Skill. Mhm. Ja. Das ist ein abgefahrenes Skill.
Christopher: Macht immer die Visols für Software Architektur und Stream, ne, von Ja.
Jan: Ja. Bei Eberhard Wolff, ne.
Christopher: Ja, ganz genau.
Jan: Guck mal,
Garrelt: Moment, Sie hatten Stream, wo Sie das macht, oder?
Jan: Nein, nein, Eberhard Wolff hat einen Stream über Software Architektur und und sie macht quasi die die Grafiken dann. Also er spricht über Architektur und parallel gibt's Grafiken und die die kommen von ihr. Okay. Und ich find, Sketchen Notes ist so ein so ein abgefahrener Skill, ja. Ich hab bei der letzten Konferenz, wo ich war, hab ich einfach gedacht, okay, ich schreib hier von Hand mit und geh danach einfach hier zu Nanobanana und sag, ey, kannst Du mir meine eigenen Notizen nicht mal in coole Sketchnotes verwandeln und das hat das nicht hingeh 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. Das ich bewundere Leute, die das können. Und auf der auf der Sukh Testkonferenz, wo ich ja auch schon länger immer rumhing, es gibt jedes Jahr Workshops zu Sketchnotes seit, weiß ich nicht, 10 Jahren oder so und jedes Mal gehe ich da rein und jedes Mal komme ich raus wie immer so, nein, ich kann das einfach nicht. Also ich mach keine Ahnung.
Christopher: Aber es ist irgendwie, ist es 'n Skill, den ich auch gerne, also ja, bin 'n bisschen neidisch. Ich hoffe, wenn ich das Buch dann durch hab und wenn ich's, man muss es einfach konsequent machen und dann irgendwann vielleicht.
Garrelt: Aber ich find's allein schon spannend, weil ich das Gefühl hab, so was wird noch relevanter, auch was die Kommunikation mit Agents angeht, weil so da irgendwann mehr High Level über den Code zu sprechen, wird's halt irgendwann sein, glaube ich, wenn Du genug Confidence hast, dass die Funktion, die er baut, schon gut genug ist.
Jan: Wer weiß, ja? Ja. Auch 'n Punkt. Ja. Mein Pick hat auch was mit AI zu tun. Und zwar Gareth wird das schon kennen, wobei andersrum, ich leite das anders ein. Mein Pick ist gar kein Pick. So. Mein Pick ist ein Tool, was Gareth jetzt gleich kennt, wenn ich das vorstelle und zwar Planetator. Wir haben es letzte Woche hier auch besprochen, glaube ich, ne, bei uns in der i-Runde hier bei Lotum. Mhm. Und zwar ist es ein Tool, was es dir ermöglicht, in den Plänen von Cloud Code et cetera quasi rumzuschreiben, da drin annotieren und so quasi noch mal ein paar Korrekturläufe zu machen, bevor die RA dann wirklich im im Execution Modus anfängt, das quasi alles umzusetzen und ich bin mit Planetator nicht zufrieden, deshalb ist es nur son halber Pick. Aber ich hätte gerne, ich hätte gerne ein Tool dieser Art. Also wer Aufruf. Ja, das ist das ein Aufruf. Also schmeißt mir eure Picks irgendwie entsprechend zu, weil ich behaupte ja nach wie vor die einzige IDI, die das richtig gelöst hat, ist irgendwie immer noch Anti Gravity. Die will man halt aus anderen Gründen nicht benutzen, aber der der der Planmodus, den sie haben, der ist halt abgefallen gut mit Du Du redest mit dem Agent, Du kannst in dem Plan rumschreiben, Du kannst den annotieren, Du kannst Assets dazufügen. Der Plan ist halt wirklich ein ein First Class Citizen sozusagen in der in der IDI irgendwie drin, ja und nicht nur son Efferal Ding, was irgendwie in deinem Chatverlauf drin hängt und das finde ich halt superwichtig. Also je 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, ja. Und mir fehlt irgendwie immer noch das Tooling, damit sauber zu arbeiten. Planetator ist schon deutlich besser als das, was die meisten dieser Tools irgendwie von Haus aus mitschippen, aber ich hab 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 und dann kann er's gerne in meine Richtung schicken. Ansonsten Leute, die ähnlich unter Plänen leiden wie ich, die können sich gerne mal Planetator anschauen. Planatator Punkt a I plan mit Doppel n, also wie anno Tat und so.
Garrelt: Ja, das Du Du benutzt das nicht, gell? Ich hab's installiert und aber noch nicht wirklich benutzt. Hab ich grad komplett verpasst oder kannst Du noch mal sagen, was Du daran nicht magst?
Jan: Okay. Also einmal zu erklären, wie so der Flow ist, also Du installierst das Plug in für Cloud Code zum Beispiel 'n Planator, installiert Planator und in dem Moment, wo dir Cloud Code im Prinzip eigentlich den Plan anzeigen würde, geht son Browserfenster auf, son kleiner lokaler Server läuft da bei dir und der Plan wird angezeigt. Ja. Und dann kannst Du son paar Kommentare da drin verlassen verfassen dann kannst Du ihm quasi einmal noch mal retour drüber laufen lassen und dann kannst Du das so oft literieren, 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 und Weiteres irgendwie mach, ja, dass der Plan vielleicht am Ende doch irgendwo auch in meinem Fallsystem, also natürlich lebt er im Fallsystem, ich hätte ihn gerne als Teil des Projektes vielleicht auch, ja, gerade vielleicht an dem Plan kollaborieren zu können, an dem Plan irgendwie als, den längerfristig aufzuheben im Repository. Also es gibt, glaube ich, so viele Sachen, die man da irgendwie noch noch machen kann und gefühlt hat das halt noch niemand so so wirklich geknackt, ja und ich glaub auch Planetator, ah, da müssten wir Dennis mal fragen, wie sich Planetator zusammen mit so Orchestrierung und so was, mit oder so verhält. Könnt ihr mir das ja auch mal anschauen. Aber ja, deswegen son halber Pick, Planetator schon ganz cool. Ich hätte gerne noch was, was deutlich cooler ist, aber solang es das nicht gibt oder mir keiner geschickt hat, nehme ich auch weiter Planetator.
Garrelt: Bau's selber.
Jan: Ja, also das hat ja auch irgendjemand in unserer Session gesagt. Ich weiß nicht, Etchenne oder so, der meinte, ja, kann man ja auch irgendwie alles selber machen, aber also ganz ehrlich, da gibt's, hast Du dich dieses Meme mal gesehen, was vor 'n paar Monaten oder so rumging, so ja, ich hab all meine Software, also Service Subscriptions losgeworden und zahl jetzt nur noch 12000 Euro im Monat an Tokens, so. Nein, so. Das das will ich halt, also ich find's immer noch cool, dass sich Leute 'n Stück Software Gedanken machen, die mehr Domänenwissen mitbringen, viel größeres Incentive haben, dass das funktioniert, so eher spezialisierte Software und Leute, die sich darum kümmern halt alles irgendwie ihren Sinn. Ich sehe keine Zukunft, in der jeder sein scheiß Stück Software, das er so braucht, irgendwie selber schreibt, aber Mai, wir reden in 10 Jahren noch mal vielleicht.
Garrelt: Moment in 6 Monaten.
Jan: Ja. Lachen wir dann alle nur noch drüber.
Christopher: Alright. Das
Garrelt: Ja, war's glaube ich Spaß gemacht.
Jan: Ja, danke Christopher. Es war ein superinteressantes Gespräch mit erschreckend wenig PHP Anteil. Ich hab schon gedacht, wir verlieren die die Hörer irgendwo zwischendrin, aber ich glaube, das war eine sehr wertvolle Diskussion viele von diesen Architekturgrundsatzfragen, die man sich halt irgendwie stellen muss, wenn man das Ganze a aufzieht und b irgendwie benutzen will.
Garrelt: Safe. Und auch
Christopher: Boah, tatsächlich egal, das stimmt. Ja.
Jan: Egal vielleicht nicht, aber zweitrangig zumindest so vielleicht, ja. Und deswegen, glaube ich, ist das superwertvoll so. Ja. Wenn ihr Fragen, Anregungen, Kritik, Vorschläge habt, dann immer gerne an Podcast at Programmier Punkt bar oder ihr kommt auf unseren supercoolen Discord Server. Wir freuen uns immer über Feedback und insbesondere über Vorschläge, Alternativen zu Planetator. Sie nehmen wir diese Woche extra gerne mit und ansonsten sprechen wir uns nächste Woche wieder. Bis dahin, 1000 Dank, 1000 Dank, Garold und wie gesagt, 1000 Dank Christopher. Schön, dass Du mal wieder da warst.
Christopher: Vielen Dank auch.
Jan: Wir sehen uns bestimmt noch mal wieder hier. Macht's gut. Bis dann. Tschau, tschau, tschau.

AI Libraries mit Christopher Hertel

Shownotes

Picks of the Day

Joy and Curiosity

Plannotator

„Sketch Notes in IT“ von Lisa-Maria Moritz

Speaker Info

Christopher Hertel