Nebu: Self-made Souveränität

Dieses Transkript wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Gil Breth: Herzlich willkommen zu einer neuen Folge des INNOQ Podcasts. Dieses Mal geht es wieder um den D-Day, den sogenannten Digital Independence Day. Dabei handelt es sich um eine Initiative, die immer am ersten Sonntag des Monats Rezepte vorstellt, wie man seine digitale Souveränität verbessern kann. Wir von INNOQ möchten auch unseren Beitrag dazu leisten und werden diesen Monat das Projekt Nemo vorstellen, das mein Kollege Philipp Beyerlein, der heute mit mir als Gast ist, als Selfmade Souveränität bezeichnet hat. Lieber Philipp, herzlich willkommen. Vielleicht magst du dich kurz vorstellen und gerne auch dein Projekt.

Philipp Beyerlein: Ja, hallo Gil. Ich bin Philipp Beyerlein, seit sieben Jahren Senior Consultant bei der Firma INNOQ. Ich habe mich in den vergangenen Jahren mit AWS-Betrieb beschäftigt, bin mittlerweile wieder in die Solution-Architektur gegangen und seit zwei Jahren beschäftige ich mich mehr mit Souveränitätsthemen. Also nicht mehr ausschließlich Betrieb auf AWS, sondern auch Alternativen, wie man mit dem Risiko und der Abhängigkeit umgeht. Dazu habe ich schon diverse Beiträge erschaffen. In den letzten Wochen kamen immer mehr KI-agentische Entwicklungen hinzu. Schon länger kam die Überlegung, kann man das nicht nutzen, um seine Souveränität zu steigern? Parallel dazu gibt es beim agentischen Engineering mehrere Richtungen. Einmal das Wipe Coding, das der ein oder andere bestimmt schon gehört hat. Ich tippe einfach irgendeine Idee ein und lasse dann alles komplett einfach machen. Das hat mir bisher nicht so gefallen, weil ich aus der Architektur komme und eigentlich mehr Struktur, mehr Kontrolle, Qualität, Tests und so weiter will. Das hat mir bei Wipe Coding immer gefehlt. Daher habe ich von Anfang an sehr viel in die Planung investiert, wenn ich etwas mit KI gemacht habe. Also immer ein Markdown erzeugen, wo der ganze Plan drin ist. Zum Glück wurde das mittlerweile formalisiert in dem Sinne von Spek-getriebener Entwicklung. Das Ganze hat einen Namen bekommen und ich habe mich in den letzten Wochen intensiv mit dem STD-Framework Bmat, ausgesprochen Build More Architected Dreams, beschäftigt. Wenn man das nun mit der digitalen Souveränität vermischt, öffnen sich plötzlich ganz neue Möglichkeiten. Das Produzieren von Software und Softwarelösungen ist jetzt mittlerweile ganz einfach geworden. Ich kann eigentlich, wenn ich es in Word beschreiben kann, es auch mit Hilfe von Spek-getriebener Entwicklung umsetzen. Es gab schon lange eine der wesentlichen Abhängigkeiten, die momentan Unternehmen oder auch Vereine generell Akteure haben, ist das Thema Kommunikation und Chat. Auf Unternehmensseite gibt es Klassiker wie Teams, Slack und so weiter. Die Chat-Kommunikation ist im Unternehmen schon strategisch wichtig geworden. Früher war es E-Mail, aber heute ist ein Chat wichtig, weil man sehr schnell asynchron kommunizieren kann, auch weltweit. Das hat schon einen strategischen Mehrwert gegenüber klassischer E-Mail und Telefon. Wenn man da jetzt Alternativen zu Slack oder Teams sucht, kommt man eigentlich zu anderen Playern wie Rocket Chat, Mattermost oder Matrix. Die sind an sich von der Strategie her Open Core. Sie haben immer eine Community-Version, aber sobald ich als Unternehmen irgendwelche Unternehmensfeatures haben will, gibt es meistens eine klassische Tabelle mit Kreuzchen. Für SSO, irgendwelche DSGVO-Sachen und so weiter brauche ich immer eine Lizenz. Die muss ich dann kaufen. Zum Teil, wie bei Jira erlebt, gibt es vielleicht eine On-Premise-Version, aber eigentlich wollen sie das nicht, sondern sie wollen, dass man es als Software-as-a-Service nutzt. Deswegen sind die On-Premise-Lösungen dann auch noch so gebaut, dass ich sie eigentlich schwer betreiben kann. Das hat mich gestört. Ich dachte, es kann doch nicht sein, dass man, wenn man sich souverän aufstellen will, Alternativen hat, aber sich nicht richtig souverän fühlt, weil ich am Ende doch wieder die Lizenz brauche oder andere Abhängigkeiten habe. Da kann ich auch gleich bei Slack bleiben. Das bringt mir überhaupt nichts. Ich habe nur eine andere Rechnungsadresse auf der Rechnung, aber die Abhängigkeit an sich zwischen meinem Unternehmen und dem anderen bleibt gleich. Wenn man das alles zusammenfasst, bin ich auf die Idee gekommen, wieso baue ich nicht einfach selbst eine Alternative?

Gil Breth: Ja, das finde ich total spannend. Ich habe letztes Jahr noch mit einem CTO darüber gesprochen, als wir ein bisschen über das Thema Abhängigkeiten seiner Softwarelandschaft gesprochen haben. Da war für mich eine Erkenntnis, als er sagte, einer meiner größten Pains ist eigentlich, wenn morgen Teams nicht mehr funktioniert. Da wurde mir erstmal bewusst, das ist so ein Commodity, wir nutzen es tagtäglich, das ist so selbstverständlich, ob das Slack ist, ob das Teams ist, ob das Zoom ist. Aber wenn das nicht mehr da ist, dann steht im schlimmsten Fall direkt das ganze Unternehmen erstmal still. Als ich dann deine Idee gesehen habe, war das für mich so ein Augenöffner, wo ich dachte, klar, man guckt immer nach Alternativen, wir kennen das alle, hast diese Matrizen mit Feature-Vergleich, Preisvergleich, aber auf die Idee zu kommen, zu sagen, ich mache das an der Stelle selber, weil das für mich ja ein so zentrales Werkzeug ist, das war für mich irgendwie ein neuer Gedanke an der Stelle. Da würde ich gerne noch mal nachfragen, wann war dieser Punkt, dass du gesagt hast, ich mache das jetzt selber, ich baue das selber? Hast du nicht vorher Alternativen angeschaut oder war für dich direkt von vorneherein klar, ich habe da mal, ich sag mal auf gut Deutsch gesagt, ich habe da Bock drauf, mal so einen Chat, so einen Kommunikationsclient zu bauen?

Philipp Beyerlein: Den Gedanken, das selber zu machen, hatte ich schon länger. Als ich mich generell mit Alternativen zu Teams und Slack beschäftigt habe, kommt man ja automatisch zu Matrix, Mattermost, Rocket Chat als Alternativen, die zumindest On-Premise betrieben werden können. Aber ich hatte eben dieses, da muss ich dann wieder, wenn ich das als Unternehmen ausprobieren will, irgendeinen Vertriebler anrufen und so weiter. Das ist alles so langwierig und zäh. Und dann hatte ich im Hinterkopf, eigentlich müsste man das selber entwickeln. Zum Beispiel ist Matrix an sich ein offenes Protokoll. Das Matrix-Protokoll selber kann jeder eigentlich benutzen. Und dann dachte ich mir schon länger, eigentlich müsste man sich hinsetzen und das mal selber programmieren. Aber als eine Person so etwas komplett zu bauen, das ist schon eine Herausforderung. Die wissen schon, dass ein Chat zu bauen nicht einfach ist. Das setzt man sich nicht einfach so mal hin in der traditionellen Softwareentwicklung. Da brauchst du eigentlich schon ein Team von drei bis fünf Leuten, die sich auch technologisch tief auskennen und so weiter. Und dann kam eben diese agentische Entwicklung mit den Sprachmodellen. Die Agenten wurden besser, die Kontextlängen wurden besser und dann kam mir schon so die Idee, wieso mache ich das nicht einfach mal mit eben agentischer Entwicklung? Aber Wipe Coding war mir dazu riskant und unstrukturiert, weil ich ja schon, wenn ich so etwas mache, habe ich ja schon, ich sag mal so, es ist ja kein Hobby, also kein Spielzeugprojekt, wo ich jetzt mal irgendwie so ein Hello World oder so etwas mache, sondern die Anforderungen sind schon komplex an so einen Chat, vor allem, wenn ich das als Unternehmen strategisch nutze. Die Firmen, die dafür Geld verlangen, verlangen ja auch nicht ohne Grund dafür Geld, weil es schon eine komplexe Aufgabe ist. Aber durch die agentische Entwicklung habe ich jetzt einen Vorteil. Ich kenne mich architekturmäßig gut aus, ich kenne Technologien, die dafür gut geeignet sind, aber ich kann sie selber nicht programmieren. Das muss ich jetzt gar nicht mehr machen, sondern das macht ja das Sprachmodell jetzt für mich. Ich habe eine Vision dazu. Und es reicht vollkommen aus am Ende. Ich muss nicht mehr selbst der Experte in irgendwelchen Messaging-Technologien oder so etwas sein, sondern ich kann die Anforderungen beschreiben, die Qualitätsziele beschreiben, die Architektur beschreiben und es reicht. Und dann die Übersetzung von dem ganzen Code, das kann ich machen lassen, einfach machen lassen.

Gil Breth: Ich finde das total schön, weil was ich daraus höre ist, du hast mehr Lust darauf gehabt, das deinen Agenten zu erklären, statt dem Vertriebler, was du möchtest. Du bist so ein bisschen der Man in the Middle übergangen oder du hast eigentlich direkt mit der Maschine, nenne ich es mal, gesprochen. Jetzt hast du eben gesagt, das war für dich eigentlich schon irgendwie klar, dass du da Lust hast, das zu machen. Ich würde gerne noch mal ein bisschen über das Wie sprechen. Kannst du noch mal zum Thema Bmat ein bisschen ausholen und das noch mal erklären, vielleicht auch konkret anhand deines Projekts? Was ist das noch mal genau für die Zuhörerinnen, die es vielleicht noch nicht kennen oder noch keine Zeit hatten, das auch mal auszuprobieren und wie bist du konkret vorgegangen, um Nemo am Ende des Tages dann doch zu bauen?

Philipp Beyerlein: Also ich habe zuerst ein paar kleine Experimente mit Bmat gemacht. Bmat ist an sich vom Grundkonstrukt her eigentlich eine Sammlung von Skills, Agenten-Skills, die eben sozusagen den Kontext deines Agenten mit bestimmten Fähigkeiten füllt. In dem Skill kann ich sowohl Soft Skills reinschreiben, hier zum Beispiel irgendwelche Entwicklungsstandards, aber auch Skripte und Templates reinpacken. Eigentlich alles Mögliche, damit ich es dem Agenten nicht jedes Mal neu erzählen muss, sondern es ist dort einmal drin. Bmat kombiniert das eigentlich immer. Die haben einen Skill, ein Skillset und nutzen dann eine vorgefertigte Schablone, um das, was die Skills erzeugen, abzuspeichern. Die Skills sind so gemacht, dass der Agent nicht selber fährt, sondern er ist sozusagen der Zuarbeiter. Er übernimmt jetzt nicht meine Entscheidungen, sondern ich sage ihm meinen Willen, er formalisiert es eben in einer Spezifikation und dann kann ich zwar schon Feedback und so weiter einarbeiten, aber er ist wie ein Interviewer. Sozusagen, wie wenn mich jetzt ein anderer Entwickler fragen würde, was willst du denn jetzt tun? Und ich sage ihm, er will das tun und gibt dann sein Wissen sozusagen aus den Skills zurück. Aber ich als Architekt oder als PO entscheide am Ende. Und dieses Muster, dass ich der PO bleibe, das behält eben Bmat gegenüber jetzt eben, wenn ich jetzt Wipe Coding mache. Da schreibe ich immer eine Idee rein und dann entscheidet er einfach das meiste, also alles auf Architektur, Qualität und so wird halt einfach nach er entscheidet es ja nicht einfach wie es, sondern anhand der besten Wahrscheinlichkeit, wie er trainiert wurde und dann kommt es halt so, wie es in den meisten Projekten gemacht wurde, kommt es halt dann raus. Und bei Bmat ist es eben umgedreht.

Gil Breth: Wie konkret war deine erste Produktvision? Wie genau muss ich es machen? Hast du einfach nur gesagt, ich möchte eine Chatlösung, oder hast du es ein bisschen griffiger gemacht? Wie bist du gestartet?

Philipp Beyerlein: Dafür bietet Bmat mehrere Einstiegsmöglichkeiten. Das sind eigentlich einzelne Schritte. Der allererste Schritt ist, wenn du eine Produktvision hast, erstellt er ein PAD File, eine Produktbeschreibung. Selbst für die Erstellung dieses PAD Files hat Bmat einen eigenen Workflow mit verschiedenen Kreativmethoden, wie zum Beispiel die Chaos-Methode oder verschiedene Hütemethoden. Die haben gängige Kreativmethoden als Skill verskriptet, die man nutzen kann. Er hat auch eigene Agenten parat für verschiedene Tätigkeiten: für Entwickler, Produktdesigner, Tester, Sicherheit und alles Mögliche. Diese Agents und Sub-Agents kann ich dann zum Beispiel zu einer Partyrunde einladen, und dann diskutieren sie über die Lösung. So kommt man immer weiter und kann sich kreativ entwickeln. Wenn man am Anfang vielleicht nur einen Satz hat, wie zum Beispiel: Ich will einen eigenen Matrix Client bauen, kommt man dann immer tiefer zu einer richtigen, ausgereiften Produktvision. Was ich damals wusste, war, dass ich Matrix nutzen wollte, weil ich mir dann kein Protokoll selbst ausdenken muss. Das Protokoll gibt es schon, so verschwende ich nicht viel Zeit mit Protokoll-Erstellung, und ich habe schon Clients, die damit funktionieren. Dann wollte ich möglichst wenig zusätzliche Infrastruktur und Abhängigkeiten haben. Da kam schon die erste Falle bei so einem Chat, weil die meisten Chat-Beispiele im Internet nutzen irgendeinen Broker wie Redis oder Ähnliches und überlassen dann das Zustellen der Nachrichten dem Broker. Publish-Subscribe ist ja das klassische Broker-Modell. Aber da ist schon wieder die nächste Falle bei Redis: Um Redis gut betreiben zu können, brauche ich auch wieder eine Lizenz. In meinem ersten Entwurf war es super, dass ich eine Art Go Gateway habe, weil Go einfach schlank ist. Ich habe mir bewusst Technologien ausgesucht, bei denen ich sage, die kann ein LLM gut lesen, ohne viel Hierarchie, ohne viel Framework-Schnickschnack, weil je tiefer mein Code wird, desto schwieriger wird es für ein LLM, das zu verarbeiten, weil es einfach unnötiger Kontext ist.

Gil Breth: Ja.

Philipp Beyerlein: Und dann war natürlich klar, eine Sprache zu finden, die sehr flach orientiert ist, wo ich wenig Frameworks brauche, wo Web drin ist. Dann musste ich aber das Broker-Problem lösen, weil ich eben kein Redis wollte. Redis-Cluster zu betreiben ist auch wieder Aufwand, da kommt wieder eine Produktvision dazu: Es soll ja auch so sein, dass es jemand betreiben kann. Die jetzigen von Matrix, es gibt ja auch eine Community Edition von Elements oder den Elements Pro Server, das ist ein richtiger Brummer. Da muss man fünf, sechs Komponenten betreiben, und das ist eigentlich schon ohne Kubernetes oder so für kleinere Betriebe fast unrealistisch, das zu betreiben, weil die dann Redis, Datenbank, drei, vier Anwendungen, irgendeinen Identity Server und alles Mögliche betreiben müssen. Ich hatte eigentlich die Idee zu sagen, das muss eigentlich so mit einem klassischen drei, vier Mann Admin-Team irgendwie machbar sein, das zu betreiben. Da habe ich mich dann erinnert, vor langer, langer Zeit hatte ich schon immer mal Erlang auf meiner Bucket List, wollte ich mich schon mal anstrengen, weil Erlang sehr viel mit Messaging zu tun hat, kommt aus der SMS-Welt und so weiter. Da hat mir das LLM auch auf die Sprünge geholfen, weil WhatsApp zum Beispiel intern auch einen Erlang-Elixir-Stack nutzt. Das ist erprobt, und die haben das lange mit ganz wenig Hardware, ganz viel geschafft, weil Erlang beziehungsweise Elixir so effizient mit dieser Nachrichtenverarbeitung umgehen kann, weil das einfach Basistechnologie im Kernel von Elixir und Erlang ist. Damit war der Bedarf eines Brokers komplett weg, nur weil ich jetzt gesagt habe, okay, ich entscheide mich für die richtige Technologie. Ich kenne selber zwar kein Erlang und so weiter, muss ich auch nicht können, aber ich kann der sagen, das ist jetzt das Bessere, und damit löse ich die Abhängigkeit, und dann macht er das.

Gil Breth: Sehr schön. Ich würde gerne noch mal ganz kurz ein, zwei Schritte zurückgehen. Erstmal, ich merke schon deine Begeisterung, und ich hoffe, dass das auch so bei unseren Zuhörerinnen ankommt, weil ich finde es schon schön, wenn am Ende der Episode jeder, der heute zuhört, in der Lage ist, das auch selbst einmal durchzuspielen. Deswegen möchte ich noch mal bei ein paar Sachen nachhaken. Jetzt hast du ja eben mit Bima beschrieben, wie dein Team, nenne ich es mal, aussah, dein Team von Agenten, und du hast auch gesagt, dass du sie dann zu einer Party eingeladen hast und dabei zugeschaut hast, was sie so diskutiert haben. Das Team ist natürlich die eine Sache, aber schauen wir noch mal ein bisschen auf die Tools. Was für Tools sind da zum Einsatz gekommen, oder welche LLMs hast du eingesetzt? Kannst du das auch noch ein bisschen erklären?

Philipp Beyerlein: Ich habe dafür jetzt hauptsächlich Cloud und die aktuellen Cloud-Modelle Sonnet und Opus genommen. Bima selbst ist agnostisch, die unterstützen auch die TPT-Modelle. Als Tool habe ich eben Cloud Code am besten damit implementiert. Man muss aber auch sagen, dass die ersten Bima-Versionen sehr stark auf Cloud fokussiert waren, auf Cloud Code, also von der Interaktion mit dem Agenten, weil es besser war. Ich habe es auch mal am Anfang mit Codex ausprobiert, aber da hat es nicht so ganz funktioniert mit diesem, weil Codex, ich weiß nicht, ob es das mittlerweile hat, aber damals hatte Codex nicht so diesen Hook-Mechanismus, also dass Sub-Agents oder Sub-Prozesse aktiv wieder zurückkommen. Diesen Hook-Mechanismus braucht Bima für diesen Agenten-Party-Modus, damit er eben sagen kann, hier, da startet der einzelne Sub-Agent mit den verschiedenen Rollen und gibt denen dann verschiedene Schnipsel, und die bewerten das dann. Das ist so ein kleines Grundmuster, das ich bei Bima immer durchziehe: Die gehen bei vielen Sachen davon aus, dass du immer mit dem neuen Kontext startest. Das sagt er auch immer wieder, dass du jetzt den Kontext lernen sollst, wenn du in den nächsten Schritt gehst, damit er eben nicht mit dem Wissen im Kontext arbeitet, sondern mit den Dingen, die du als Plan, als Spezifikation erzeugt hast. Sonst klammert er halt wieder in irgendeinem seinem Kontext, irgendwie in seinem Memory rum und folgt nicht dem, was du vielleicht spezifiziert hast.

Gil Breth: Ja. Okay, spannend. Ich finde es so faszinierend, weil du hast jetzt das Team, du hast irgendwie deinen Tool Stack, und da stellt sich mir dann immer die Frage die ganze Zeit dabei, welche Rolle spielst du denn? Also du als Mensch, wo greifst du ein, wo lässt du es einfach laufen? Wo sagst du mal, ich ändere vielleicht noch den Tool Stack oder passe irgendwelche Entscheidungen an? Gab es für dich so ein paar Punkte, wo du festmachen konntest, da muss ich jetzt mal irgendwie eingreifen?

Philipp Beyerlein: Ich bin immer noch der Lenker am Ende. Man kann es sich wie ein Auto vorstellen. Ein Auto mit Automatik macht auch vieles. Man muss sich nicht über Zündzeitpunkte im Motor Gedanken machen, das macht es alles für einen. Man muss sich aber überlegen, wohin man fährt und ob man performant unterwegs ist. Am Anfang, als ich in die Umsetzung ging, konnte ich eine Story erstellen, daraus den Code generieren und ihn dann reviewen. Das war relativ einfach und hat für den Ramp-up des Projekts gut funktioniert. Aber dann wurde es komplizierter, besonders das Matrix-Protokoll selbst hat ein paar Fallstricke. Sie haben eine API, an die ich etwas schicken kann, und der Client hat einen Sync-Endpoint, von dem Events zurückkommen. Dieses Sync-Event-Verhalten hat mich lange beschäftigt. Ich habe die Rolle des Abnehmers, des Users, des Endkunden eingenommen und sozusagen den Endkundentest gemacht. Ich habe einfach den Matrix-Client gestartet und geschaut, ob ich chatten oder mich einloggen kann. Dann habe ich Feedback gegeben und gesagt, das ist falsch. Irgendwann, weil der Fehler immer wieder nicht gefunden wurde, dachte ich mir, jetzt muss ich wie in einem klassischen Softwareprojekt vorgehen, wenn ich Fehler habe. Was mache ich dann? Welche Strategien habe ich? Ich habe die Teststrategie erhöht. Es gab von Bima ein Testautomatisierungsmodul, das habe ich eingebaut. Ich habe mir eine Mini-Pipeline gebaut, die die Schritte enthält, und diese in die Testabdeckung und Teststrategien integriert. So habe ich das weiterentwickelt. Irgendwann kam auch das Thema Security auf. Wenn ich sage, Matrix-Server, das hat in der Community eine hohe Messlatte. Man darf sich sicherheitstechnisch keine Patzer erlauben, sonst ist man raus. Dann habe ich einen eigenen Agenten, Cassandra zum Beispiel, hinzugebaut, der im Review oder immer wieder die Pipeline aktiviert, wenn es um Security-Themen geht. Ich habe explizit gesagt, die Features sollen OWASP-Fähigkeiten haben und kritisch sein. Nicht panisch, aber kritisch. Man kann den Agenten so ein bisschen Charakter geben, wie sie arbeiten sollen. Irgendwann hatte ich dann die Sicherheit, dass sich jemand um die Security kümmert. Aber es kamen immer wieder Fehler mit dem Matrix-Protokoll auf. Das LLM hatte zwar Matrix eintrainiert bekommen, aber gerade dieses Event-Rückspielung und so weiter, das war schwierig. Dann dachte ich, ich mache mir noch einen anderen Agenten, der sich nur mit der Fachlichkeit des Matrix-Protokolls auskennt. Der soll dann entsprechende Reviews geben. So hat sich mein Entwicklungsset immer weiterentwickelt. Das ist eigentlich die Aufgabe. Ich muss jetzt nicht den Code schreiben, aber ich bin trotzdem dafür verantwortlich, dass aus meinen Produktideen funktionierender Code entsteht, der qualitativ hochwertig ist. Wenn ich zum Beispiel sage, ich will Compliance-sicher sein, dann habe ich Qualitätsziele, auf die ich hinarbeiten muss. Das muss ich kontrollieren und machen. Ich habe den Code bisher nicht viel gesehen, bin ich ehrlich. Aber das, was ich gesehen habe, ich habe am Anfang den Trick gemacht, ihm gesagt, er soll möglichst flach alles machen. Es gibt zum Beispiel kein Entity-Modell in meinem Code, weil mein Entity-Modell in meinen SQL-Skripten steht. Der Entwicklungsagent nutzt das permanent. Er kennt das SQL-Schema, also kann er auch die entsprechenden SQL-Statements schreiben. Ich habe kein Framework, das ich verstehen muss, sondern eigentlich nur den API-Request und das entsprechende SQL-Statement dazu. Das kann ich super einfach selbst lesen. Ich kann jederzeit reingucken und verstehen, was er tut.

Gil Breth: Ja, ich muss da einmal einhaken, weil da stecken ja eine Menge Entscheidungen drin. Du hast eben gestartet mit der Aussage, du siehst dich da als Lenker. Du hast gar nicht mehr so sehr in den Code vielleicht auch eingeschaut. Vielleicht hat er dich überhaupt interessiert. Hand aufs Herz.

Philipp Beyerlein: Nee.

Gil Breth: Nee.

Philipp Beyerlein: Mich hat interessiert, dass die Tests und die Fachlichkeit funktionieren. Das interessiert mich.

Gil Breth: Ja, aber was ich daraus höre, sind ja auch eine Menge architektonischer Entscheidungen. Da würde mich natürlich schon interessieren, hast du dich vorher hingesetzt und dir solche Dinge, wie du es eben gesagt hast, dass du es flach halten möchtest, vorab Gedanken gemacht und mal niedergeschrieben, oder hat sich das so entlang des Weges entwickelt, dass du das Stück für Stück aufgebaut und eingefügt hast? Das sind ja schon weitreichende Entscheidungen. Wie bist du da vorgegangen, was gerade diese, ich nenne es mal, weitreichenden Architektur-Entscheidungen angeht?

Philipp Beyerlein: Was die Struktur angeht, stand das eigentlich in der zweiten Datei, die immer nach dem PRD, dem Architektur-File, angelegt wird. Ich wollte absichtlich etwas schaffen, das ein LLM gut bauen kann. Dann macht es natürlich Sinn zu sagen, ich optimiere den Code jetzt nicht für den Menschen, sondern für das LLM. Ich habe in anderen Projekten schon versucht, zum Beispiel bei Java-Projekten, mit Vererbung zu arbeiten. Vererbung ist tödlich für ein LLM, weil es so viel Wissen aufbauen muss, um zu verstehen, was passiert. Ich wollte es einfach mal andersherum machen, als wir Menschen es machen, sondern für ein LLM. Denn wenn wir mal ehrlich sind, diese ganzen Frameworks wie Spring und so weiter, die machen eigentlich auch nur einen HTTP-Request in ein SQL-Statement übersetzen. Was anderes machen die ja nicht, mit ganz viel Code dazwischen. Und wieso haben wir das dazwischen? Weil wir Menschen natürlich eine begrenzte Kapazität im Kopf haben. Wir können nicht eine Million Tokens auf einmal im Kopf verarbeiten und vergessen dann etwas. Deswegen brauchen wir immer diese Sicherheit. Man hat sehr viel auf den Compiler abgewälzt, dass der Compiler einem sofort sagt, okay, da habe ich mich jetzt vertippt, dort habe ich jetzt falsch gemacht, dort passt mein Modell nicht und so weiter. Wir haben diesen Kontextschutz dem Compiler nach und nach aufgedrängt. Aber das braucht man bei dem LLM nicht. Der hat es ja im Kopf, ich habe das ja in meiner Spezifikation niedergeschrieben. Der respektiert es ja, was ich da niedergeschrieben habe. Deswegen kann ich einfach sagen, okay, mach den Code so flach wie möglich, bau keine künstlichen Hierarchien ein, nur da, wo es irgendwann Sinn macht, ein bisschen zu modularisieren. Wenn ich sage, okay, ich habe jetzt hier zum Beispiel die Connect-Sachen, wo ich sage, ich habe jetzt hier Filter, die für mehrere gelten, so Aspekt-mäßig, das kann man schon machen, aber sonst ist es halt sehr flach. Ich nutze bewusst auch möglichst wenig Frameworks, weil ich es halt einfach selbst machen lassen kann. Das war von Anfang an eine Idee, die ich schon länger im Kopf hatte: Wieso macht man das nicht eigentlich so und löst sich einfach mal von diesem Code? Bisher, wenn ich mit Kollegen spreche, hängen die noch immer sehr am Code. Ich sage eigentlich, ich muss mehr am Test hängen. Der Test ist meine verschriftete Spezifikation am Ende. Und wenn der Test funktioniert, ist mir doch der Weg dazwischen nicht mehr so wichtig. Ich weiß, der Test funktioniert. Deswegen investiere ich doch mehr in die Spezifikation und die Tests als in den Code. Und wenn ich den Code einfach halte, bewusst einfach halte, dann kann ich den auch jederzeit lesen. Ich habe ihm jetzt nicht gesagt, er soll nur Variablen mit zwei Buchstaben benutzen, das macht er nicht, aber ich sehe halt sozusagen meine betreute Domain in Code übersetzt. Da fängt nicht plötzlich an und schreibt irgendwas anderes in den Code, als sein Kontext hat. Das macht er halt auch nicht.

Gil Breth: Da stellt sich natürlich die Frage, wie viel Vertrauen gebe ich da rein, wie viel Erfahrung habe ich auch, das bewerten zu können, dass ich den Gedanken gegen den Richter ganz spannend finde an der Stelle. Ich würde aber gerne noch mal auf Nemo selbst zurückkommen und zwar diese Lösung, die du gebaut hast. Wenn wir das jetzt noch mal ein bisschen, du hast ja eingangs von Enterprise-Features, weil kostenpflichtigen kommerziellen Alternativen gesprochen. Also welche Enterprise-Features hast du denn jetzt im Detail da eingebaut? Also was steckt in Nemo drin, dass es Enterprise-fähig machen könnte?

Philipp Beyerlein: Es gibt ein paar Dinge, die bei Enterprise immer kostenpflichtig sind. Das ist einmal die Möglichkeit, Open ID Connect, also Single Sign-On, zu nutzen. Man muss sagen, in der Community gibt es zwar mittlerweile auch die Möglichkeit, einen Open ID Connect Server anzubinden, aber es gibt kein richtig cooles Rollen- und Rechtekonzept, da es nur eine weitere Authentifizierung ist, aber keine richtige Autorisierung. Für mich war von Anfang an klar, dass Open ID Connect standardmäßig enthalten sein muss. Dann brauche ich das Thema Compliance, denn das ist der große Unterschied zu anderen Matrix-Lösungen. Diese sind dafür gedacht, dass ich einen Matrix-Server für eine unbekannte Gruppe von Leuten betreibe. Ich bin sozusagen der Betreiber eines Chat-Servers. Aus Unternehmenssicht ist das anders, denn alles, was ich mit diesem Server kommuniziere, gehört der Firma. Also muss es einen Compliance-Support geben. Matrix selbst hat eine Ende-zu-Ende-Verschlüsselung, die ich bewusst erstmal weggelassen habe. Sie wird vielleicht kommen, wenn jemand sie unbedingt haben möchte. Aber wenn ich als Firma einen Chat für meine Mitarbeiter zur Verfügung stelle, muss ich jederzeit auskunftsfähig sein, was über diesen Chat kommuniziert wurde. Wenn zum Beispiel jemand ein Verbrechen über dieses System plant, muss ich das auf staatsanwaltliche Anordnung ausgeben können. Bei Bedarf. Deswegen habe ich im MVP schon einen Compliance-Flow, der ein Vier-Augen-Prinzip vorsieht. Ich kann sagen, ich möchte von folgenden Teilnehmern folgende Chatverläufe haben, und setze dann eher auf Signaturen, damit diese Compliance-Reports entsprechend signiert sind. Das sind Features, die es eher in den Enterprise- oder Lizenzpflichtigen Versionen gibt. Als dritter Punkt kommt die Skalierbarkeit. Die richtige Skalierungsstrategie gibt es meistens nur gegen Lizenz. Als Community habe ich vielleicht kein Lizenzproblem, wenn ich 50 bis 100 Leute habe, das kann ich bequem ohne Skalierung machen. Aber wenn ich plötzlich 10.000 oder mehr Nutzer habe, brauche ich Skalierung und Ausfallsicherheit. Es geht dann eher um Skalierung, dass ich einen Cluster habe, wo ich bei Ausfall tauschen kann, Rolling Updates machen kann und so weiter. Das waren alles Features, die hinter der Lizenz versteckt sind, wobei ich mir denke, dass es aus Architektursicht heute kein Hexenwerk mehr ist, etwas skalierbar zu bauen, Open ID Connect einzubauen oder einen Compliance-Flow zu implementieren. Auch das Thema DSGVO ist wichtig. Zum Beispiel, dass wenn jemand eingeloggt ist und seine persönlichen Daten hat, er einen Schlüssel bekommt, der verschlüsselt ist. Mein Server kann es entschlüsseln, und wenn der Mitarbeiter das Unternehmen verlässt, wird einfach nur der private Schlüssel weggeworfen, und niemand kann mehr den Klartextnamen sehen. Das sind kleine, feine Sachen, die eigentlich nicht schwer umzusetzen sind, aber bewusst kostenpflichtig sind. Deswegen habe ich bei Nemo gesagt, das ist von vorneherein drin. Dafür verzichte ich auf eine Ende-zu-Ende-Verschlüsselung oder auf Federation, was Matrix auch kann. Federation ist eigentlich das Skalierungsmodell des Matrix-Protokolls, dass ich verschiedene Matrix-Server bei verschiedenen Menschen hosten kann, ähnlich wie Mastodon, und die sind dann über Federation miteinander verbunden. Für einen Unternehmenskontext, einen Closed Loop, ist das aber nicht nötig. Vielleicht irgendwann mal, wenn man sagt, okay, ich will mit anderen Nemo-Servern auch kommunizieren. Teams und Slack haben irgendwann auch eine Federation eingeführt, aber es ist jetzt nicht das Must-Have eines Unternehmens-Chats, weil ich ja eigentlich meine geschlossene Gruppe damit sichern will, nicht zu anderen. Das ist ein nettes Goodie, was man dann irgendwann noch hat, aber die Federation ist ein großer Brocken im Matrix-Protokoll, der mir keinen Gewinn gebracht hätte. Deswegen habe ich ihn bewusst weggelassen, mit Fokus auf mehr Enterprise-Features.

Gil Breth: Ja, du hast eben oder schon davor auch mehrfach das Thema der Kosten erwähnt. Jetzt muss man natürlich fairerweise sagen, das, was du mit LLMs oder auch mit BMAT erzeugt hast, das war ja auch nicht kostenlos. Wie sieht’s denn aus mit Kosten? Was kannst du denn dazu berichten? Was sind deine Erfahrungen, worauf sollte man auch achten, vor allen Dingen?

Philipp Beyerlein: Also bei Kosten, wenn man das mit LLMs macht, ist der Tokenverbrauch bei generell spekgetriebener Entwicklung wesentlich höher, weil ich einfach mehr niedergeschrieben habe. Es ist aber jetzt nicht so, dass ich zwanghaft immer endlos Tokens ohne Limit brauche, um etwas zu schaffen, sondern es ist ja an sich, in meinem Fall zum Beispiel, nicht zeitkritisch. Es gab ja keinen Zeitdruck, und ich konnte ihn einfach machen lassen, parallel mein ganz normales Kundengeschäft betreiben und ab und zu mal reinschauen, wie weit er ist.

Gil Breth: Mhm.

Philipp Beyerlein: Und ob es passt. Dann teste ich ab und zu mal, gebe ihm eine Kurskorrektur, und dann fährt er wieder von alleine. Das ist eben der Token-Invest, der mehr zu beziffern ist. Ich sag mal so, ein höheres Limit-Kontingent, eine Lizenz, liegt bei 100 bis 200 Dollar im Monat. Damit kann man schon sehr viel erreichen, weil man ja dieses Limit hat, und nur ein volles Limit ist ein gutes Limit. Man würde ja dann auch verschenken, und die Limits kann ich ja auch einfach ausfüllen, das schadet ja nicht. Was man sich dann denken muss, was man dagegenrechnet, ist: Ich habe jetzt hier vielleicht anderthalb Monate gearbeitet, und wenn ich das traditionell besetzen würde, müsste ich jeden dieser Agents als Person erfassen. Also ich bräuchte, um den Nemo-Server als klassisches Softwareprojekt zu realisieren, drei bis vier Leute, die das leisten. Drei bis vier Leute anderthalb Monate kostet ja, das kann sich jeder selbst ausrechnen, wie viel da verloren geht, und die können dann nicht parallel noch Kundengeschäft machen.

Gil Breth: Ja.

Philipp Beyerlein: Und das Endergebnis ist ja, dass ich mich dann unabhängiger mache, also strategischer Gewinn, und ich spare mir die Lizenzkosten für das Produkt, das ich dadurch ersetze. Chat ist jetzt, sage ich mal, der Worst Case. Ich fange fast Greenfield an, das Matrix-Protokoll gibt es schon, aber fast Greenfield. Aber wenn man jetzt sagt, okay, ich habe jetzt hier ein Open-Source-Projekt, das gibt es schon. Ich hätte auch nichts gehabt, wenn es einen passenden Matrix-Server gäbe, wo man sagt, okay, da muss man jetzt einfach nur ein bisschen rumbasteln, wäre das ja auch möglich gewesen. Aber ich wollte jetzt hier einfach mal auch ein bisschen das BMAT testen und die spekgetriebene Entwicklung, weil man muss da klar sagen, das ist auch bewusst nur etwas für richtig schwere Probleme. So kleine Sachen, ich habe es auch mal versucht für ein bisschen Infrastruktur, Cloud Formation machen und so, das ist zu viel. Das ist einfach eiskalt zu viel. Da verbringt man so viel Zeit mit erstmal erklären, Speck aufbauen, und da hat man es mit Vibecoding schneller. Klar. Also so kleine Sachen, aber wenn ich jetzt ein richtig großes Problem habe, dann ist es mit BMAT schon auf Produktentwicklungsniveau, was man dann haben muss.

Gil Breth: Das bringt mich aber zu einem Punkt: Bei aller Euphorie, ich finde das ja wunderbar, das klingt auch gut, aber wenn wir jetzt mal nachhaltig denken, jetzt steht das Produkt da. Es muss aber auch gepflegt werden, gewartet werden, Sicherheitspatches eingespielt werden. Was ist, du kennst das Busproblem oder Truckproblem, du hast es jetzt im Alleingang gemacht, sag mal, du bist morgen nicht mehr da, aus welchen Gründen auch immer. Wie geht’s denn mit so einem Projekt weiter, wo ich ein voll agentisches Team eventuell dran gesetzt habe und die Schöpferin oder der Schöpfer aus welchen Gründen auch immer irgendwie nicht mehr greifbar ist? Oder das skaliert im Sinne von viele Mitarbeiter, was ist denn das? Also, wie geht man denn mit sowas dann professionell um an der Stelle? Hast du da auch direkt ein paar Empfehlungen?

Philipp Beyerlein: Da kommt wieder die Spezifikation zum Tragen, und zwar war mir von vorneherein wichtig, dass ich nicht verstecke, dass ich es agentisch entwickelt habe. Es gab mal von Cloudflare einen vibecodeten Matrix-Server, der dann gerade die entscheidenden Dinge gar nicht implementiert hatte, nur die API, also das Interface. Und so etwas ist natürlich schwer. Aber wenn ich es mit diesem spekgetriebenen Ansatz mache, habe ich jede Story, alles ist dort drin, auch meine eigenen Agents, die ich gebaut habe, alles drin. Also jeder, der einen Cloud Agent hat, kann sich das auschecken und weiterbauen, weitermachen. Und das steht da alles drin. Also, und wenn ich selber gar nicht so, ich könnte es auch händisch machen, könnte man es auch weiterentwickeln. Ist die Frage, ob das dann, aber ich habe ja, ich kann auch einfach nur einen Agent nutzen, der mir erklärt, was drin ist. Da steht ja alles da, es ist nichts versteckt, möglichst wenig implizites Wissen, sondern möglichst viel explizit niedergeschrieben. So kommt man dann auch wieder rein. Ich habe es auch schon mal getestet, mal ein zweites Projekt parallel ausgecheckt, neu aufgesetzt, und da kann man dann einfach nahtlos weiterarbeiten an den Sachen. Und da ist halt wichtig, dass man transparent ist, was das angeht. Dass man auch wirklich sagt, okay, hier sind alle Stories, und das zwingt eigentlich das BMAT oder die spekgetriebene Entwicklung dazu, weil ich eben nicht so viel auf den Kontext vertraue. Weil sozusagen das Kontextwissen ist ja nicht fest, ist ja nur lokales temporäres Wissen. Und wenn ich natürlich eben nur im Kontext arbeite, sind halt natürlich vielleicht in manchen Entscheidungen so, sind halt dann weg, und so sind die alle sauber als ADR dokumentiert. Ich habe eine Akt 42 Doku mir aus meinen Stories, aus meiner Architektur raus generieren lassen, so ist alles, alles, alles ist da.

Gil Breth: Mhm, mhm.

Philipp Beyerlein: Auch wenn ich nicht.

Gil Breth: Das ist der letzte Wunsch, den man manchmal hat, dass solche Dinge da sind, und jetzt sind sie da, weil die Fleißarbeit, die damit verbunden ist, natürlich von den Agenten zum Teil auch erledigt wird. Aber nichtsdestotrotz, wenn man mal ein bisschen in die Zukunft springen würde, wenn du der Zukunfts-Philipp irgendwann zurückschaust oder vielleicht auch heute schon, nachdem du ein paar Wochen in die Zeit investiert hast, gibt es doch sicherlich trotzdem ein paar Dinge rückblickend, die du vielleicht anders entschieden hättest. Gibt es da etwas, wo du sagst, wenn ich das Projekt jetzt noch mal neu aufsetzen würde, das würde ich anders machen?

Philipp Beyerlein: Klar, was ich anders machen würde, das ist bei traditioneller Software so: Ich würde viel stärker von vornherein testgetrieben und behaviorgetrieben entwickeln.

Gil Breth: Mhm.

Philipp Beyerlein: Dazu gibt es sogar eine lustige Anekdote: Ich habe ja eben das Matrix-Protokoll erwähnt, dafür gibt es ja schon Clients. Und für diesen Event-Mechanismus habe ich lange gebraucht, bis ich darauf gekommen bin: Ich nehme den Element Web Client, der hat eigene Playwright-Tests. Wieso adaptiere ich nicht einfach die Playwright-Tests von diesem Element Client, um die Matrix API zu testen, die Matrix Spec zu testen? Und eben gerade, dass ich einen Agenten habe, der sich mit diesem Matrix-Protokoll, mit dem eigentlichen Problem, auskennt, das würde ich, wenn ich jetzt ein neues Projekt mit Spec-getrieben mache, mir die Zeit nehmen und für meine ganzen Business-Sachen mehr analysieren und das versuchen, in eigene Skills und Agents zu packen, die dann aktiv in meinen Story-Schreibprozess, in den Entwicklungsprozess, auch im Review, gerade dieses Review, das ist echt, weil wenn der was erstellt, auch Code oder Stories, das ist meistens ein One-Shot, das kann man sich vorstellen wie ein Mini-Vibe-Code-Artefakt. Und der braucht einfach diesen Review-Prozess.

Gil Breth: Mhm.

Philipp Beyerlein: Da findet er immer irgendwas, immer. Deswegen ist zum Beispiel auch diese Party-Runde so wertvoll, weil da findet er, ich finde immer irgendwas. Eine Lücke, wo man denkt, okay, ist eigentlich ganz gut, aber die haben dann immer noch eine Lücke gefunden, wo man sagt, ja, klar, das muss rein. Weil man plötzlich die Möglichkeit hat, gleichzeitig auf ganz viele Köpfe mit ganz viel unterschiedlichem Wissen zuzugreifen. Und das auf Knopfdruck. Und das muss man, glaube ich, das ist ein anderes Arbeitsmuster, was man jetzt mit dem ganzen Engineering hat.

Gil Breth: Ja.

Philipp Beyerlein: Und wenn man ehrlich ist, das hatte man ja früher auch schon in traditionellen Softwareprojekten, wenn man angefangen hat und dann hat man eigentlich eher auch so selber einfach runtergescriptet damals und dann hat man auch, nee, die Qualität, die passt irgendwie nicht, dann hat man Tests aufgesetzt, CI aufgesetzt. Eigentlich müsste man ja heute schon viel weiter sein im Kopf. Was denken, weil ich glaube, das sind tradierte Verhaltensmuster, oder?

Gil Breth: Ich glaube, das sind tradierte Verhaltensmuster, oder?

Philipp Beyerlein: Das ist ja nicht trainiert worden mit den besten Softwareprojekten, sondern ihr kennt ja, 95 % der Softwareprojekte sind ja die schlechtesten gewesen.

Gil Breth: Genau, so wurde ja die LLM trainiert. Ja, genau.

Philipp Beyerlein: Ich glaube, bei LLMs geht man manchmal davon aus, dass sie programmieren können, aber sie sind eher wie jemand von der Straße, der vielleicht auch programmieren könnte. Der kann auch irgendwas runtertippen, aber erst diese Skills und so weiter, das macht dann aus einem Generalisten einen Spezialisten.

Gil Breth: Mhm. Ja.

Philipp Beyerlein: Und da muss man, glaube ich, als Firma, wenn man da anfangen will, generell auch für jetzt nicht so etwas wie Nibu, langfristig die Architekturarbeit in diese Skills stecken. In dieses Setup. Und dann habe ich aber auch die Möglichkeit, wie ich jetzt zum Beispiel mit meinem Matrix Agent oder mit meinem Sicherheitsagenten gleich von vornherein irgendwelche Compliance Rules und so weiter gleich mit umzusetzen, direkt mit reinzugeben, um dann nicht hinterher festzustellen, jetzt habe ich zwar etwas produziert, aber ISO irgendwas-kompatibel ist es jetzt nicht. Sondern ich kann mir dann einen ISO-Agenten bauen, der das gleich von vornherein mitmacht. Und das war so ein bisschen eine Erkenntnis, auch gerade in den letzten Wochen, wo ich viel Bugfixing gemacht habe, was mich dann irgendwie genervt hat, ja, wieso macht er das jetzt nicht? Jetzt hat er wieder das Event vergessen.

Gil Breth: Ja.

Philipp Beyerlein: Weil er halt dann mit neuem Kontext anfängt und klar hat er vielleicht ein bisschen irgendeinen Stand mal beim Training vom Matrix-Protokoll reingekriegt. Aber sich dann einfach mal 5 Minuten hinzusetzen und sagen, okay, es gibt den Skill zum Skill bauen. Hier hast du den Matrix-Spec, mach mir einen Skill draus. Das sind ein paar Token, die ich da investiere, aber dann später habe ich halt ein viel besseres Ergebnis.

Gil Breth: Ja. Ich merke schon, ich glaube, es macht total Sinn, dass wir eine separate Folge alleine zu diesem Thema aufnehmen, weil ich höre, ich habe es vorhin schon mal gesagt, eine totale Begeisterung heraus und ich glaube, das macht an der Stelle absolut Sinn, dass wir da vielleicht noch mal drüber nachdenken. Ich habe es mir schon mal zumindest notiert. Ich habe dich eben gefragt, rückblickend, was du anders machen würdest. Jetzt machen wir mal den Blick nach vorne, was steht denn auf der Roadmap für Nibu? Was sind denn die nächsten Meilensteine?

Philipp Beyerlein: Die nächsten Meilensteine, die ich habe, es gibt bei, also noch ein bisschen ein paar Features aus dem Matrix selber raus. Zum Beispiel gibt es auch die Möglichkeit, Spaces zu schaffen, also eine Spezialform von Räumen aus dem Matrix, wo ich eben auch Spaces habe. Die sind, ich habe sozusagen die Matrix-Features ein bisschen in MVP Phase 2 und Phase 3 eingeteilt. Momentan bin ich in Phase 2.

Gil Breth: Mhm.

Philipp Beyerlein: Im MVP-Umfang hatte ich halt so ein großes Grund-Setup von einem ganzen Projekt, dann eine Art Bootstrap-Phase, wo ich meinen Nibu-Server mit einem Open ID Connect Server verbinden kann, wo dann alles eingerichtet ist. Also es gibt einmal die Matrix-API und dann habe ich so eine Admin-Oberfläche dazu gebaut, wo man halt so User sehen kann, Räume sehen kann, ein bisschen Zustand sehen kann und eben das Onboarding machen kann mit einem Open ID Connect Server und zum Beispiel Claim Mappen und so weiter. Und das war alles in eins und so Grund-Matrix-API-Features. Also, dass ich mich einloggen kann, dass ich eine Nachricht schicken kann. Und dann in der Phase 2 kam dann mehr, dann noch hinzu, dass ich eben die Admin-UI ausgebaut habe, eben so etwas wie Raummanagement, User-Management, das hatte ich im MVP nicht, war jetzt nicht entscheidend, um überhaupt mal etwas Zeigfähiges zu haben, was Lauffähiges zu haben. Das kam dann eben später. Und da sind dann auch immer wieder eben Bugs, was dieses Eventing anging, mal aufgetreten. Und jetzt, was jetzt für die nächste Iteration kommt, ist das Thema Medien-Handling, also, dass man eben auch Bilder hochladen kann und so weiter, das ist eine eigene Sektion im Matrix. Und dass man zum Beispiel auch mit irgendeinem Object Store dann verbinden kann. Und dann, was bei Matrix auch noch drauf kommt, ist eben dieses mit den Spaces, dass ich eben für verschiedene Projekte zum Beispiel Spaces anlegen kann. Genau. Was dann ist es weitestgehend fertig, was so die normalen Features angeht.

Gil Breth: Mhm.

Philipp Beyerlein: Und dann habe ich noch so ein paar Ideen, was man, was langfristiger ist, zum Beispiel, dass ich die Admin-Oberfläche, das was halt auf Admin-Seite läuft, dass es einen eigenen Raum gibt, mit einem Agenten, mit einem virtuellen User, wo dann zum Beispiel jemand mit dem, zum Beispiel Meldungen, Warnings und so weiter, wo da drauf tauchen, wo dann das die Admin-Oberfläche selbst als Chat. Der Nibu selber selbst der Chat-Fütterer ist und über Inhalte zum Beispiel oder Aufgaben oder zum Beispiel für das Compliance-Thema, dass wenn jetzt jemand ein Compliance aus der Compliance Officer, der dann auch hätte auch dann Möglichkeit Zugang zum Chat, beantragt einen Compliance und dann kriegt er eine Nachricht über einen Nibu-Chat. Die Compliance-Report wurde erstellt, kannst du hier runterladen und so was. Also, das ist ein bisschen mehr noch ein paar mehr Management-freundliche Sachen gibt oder eben was ein schwieriges Thema ist, ist jetzt bewusst noch hingestellt, ist eben das Thema End-to-End-Verschlüsselung. Ich persönlich finde es schlecht, dass dann auf dem Client, der sagt dann immer unverschlüsselte Nachricht, ich finde es schon gut, aber eben bei dem Verschlüsselung selbst. Es gäbe die Möglichkeit das zu lösen, auch dass ich Compliancemäßig ein gutes habe, aber die Matrix-Clients unterstützen das nicht tatsächlich. Das nennt sich Escrow Key, das ist so, dass die Nachrichten dann im kleinen doppelt verschlüsselt werden, einmal über den normalen Matrix-Schlüssel, dass die halt innerhalb der Matrix-Welt verschlüsselt sind und dann parallel noch mit einem zusätzlichen zweiten Schlüssel, der dann von dem Hauptschlüssel entschlüsselt werden kann. Für diese Compliance-Geschichten. Aber diese Doppeltverschlüsselung kann ein Client nicht.

Gil Breth: Mhm.

Philipp Beyerlein: Und da kommt noch ein Punkt, wenn die API soweit steht, und zwar das Thema Client. Ich will natürlich bei einem Chat auch Push-Nachrichten und Notifizierungen haben. Die offiziellen Element- oder Matrix-Anwendungen laufen ja unter der Element-ID. Ich kann zwar den Element Push Server benutzen, aber dann bin ich wieder abhängig. Ich will ja vielleicht meinen eigenen Client haben. Und da kommen wir zu einer spannenden Sache: Es gibt einen Client, der nennt sich Fluffy Chat, der ist von der Lizenz her, glaube ich, sogar Apache 2 Lizenz. Mir kam schon während des ganzen Überlegens die Idee, dass man diesen Fluffy Chat Client nehmen könnte, ein eigenes Modul dazu, wo ich den customizen kann. Auf meine Firma, auf mein eigenes Branding, da kann ich meine eigenen Farben reinmachen und dann kann ich diese App eben selber in einem App Store deployen und meine eigene Domain oder auch über Apple mit privaten Apps deployen, wenn ich das Zertifikat habe. Und dann kann ich eben daraus meine eigene Chat-App bauen. Wenn ich das als Spezifikation habe, ich habe vorhin schon mal so ein bisschen mit Open Source angefangen, das war dann so ein Aha-Effekt. Damals zu sagen, hey, ich kann ja sozusagen als Teil von Nibu dieses Customizen selber als Spezifikation anbieten. Dann habe ich eben ein Fluffy Customizing Modul, der fragt mich dann, ja, wie sind denn meine Farben, wie heiße ich und so, und dann customizet er mir das alles. Weil wenn ich das einmal selber für mich mache, kann ich mir auch eine Spezifikation erzeugen, was ich ändern muss, und dann kann ich daraus wieder einen Skill bauen und anderen zur Verfügung stellen. Und das hört sich vielleicht so an, aber das eröffnet plötzlich Möglichkeiten, die es vorher gar nicht gab. Was wäre vorher der traditionelle Weg gewesen? Ich mache einen Fork bei GitHub, dann muss ich mich in das Projekt einlesen, muss die Architektur verstehen, mich mit dem Contribution einlesen und dann muss ich die Stellen finden, die ich ändern will, dann kann ich das anpassen und dann kam irgendwann vom Hauptknoten wieder ein Update und dann muss ich alles wieder mergen. Und das regelmäßig, und das ist halt sehr aufwendig auf Dauer. Aber wenn ich das eben in eine Spezifikation, ein primitives Markdown-File, reinpacke, was ich geändert haben will, dann kann ich das ja auch einen Agent machen lassen. Dann mache ich mir halt einen Agent, einen Fluffy Customizer Experten, der kennt sich mit dieser Fluffy Architektur aus. Der sucht sich dann schon die richtigen Stellen aus, der Reverse Engineering, das können die LLMs ja, das ist ja Buttergeschäft, sage ich mal. Und dann habe ich da die Möglichkeit, einfach meine eigenen Features, die ich gerne hätte, zum Beispiel eben eigenes Branding oder eben, dass gar nicht beim Anmelden nach Registrieren und so weiter gefragt wird, dass das rausgeschmissen ist, und solche Sachen kann ich dann einfach reinmachen oder eben zum Beispiel diese erweiterte Ende-zu-Ende-Verschlüsselung, kann ich da dann einfach mit reinprogrammieren, wo ich dann Compliancemäßig eine gute Ende-zu-Ende-Verschlüsselung habe.

Gil Breth: Ja.

Philipp Beyerlein: Und wenn ich das Muster dann auch auf andere Sachen anwende, dann wird’s spannend. Viele von den Zuhörern kennen vielleicht diese klassische Make-or-Buy-Entscheidung. Und da haben wir dann eben Make, und bei Buy hat man dann vielleicht so zwei, drei Kandidaten und oft ist auch irgendeine Open-Source-Variante dabei. Aber die passt halt nur zu 95 %, die würde eigentlich gut passen, aber so ein bisschen, zum Beispiel Login mit SSO ist halt nicht drin, oder irgendwelche branchenspezifischen Sachen sind halt nicht drin. Das sind halt so ein kleines Quäntchen fehlt, aber es wäre eigentlich gut.

Gil Breth: Wo man dann oft in Unternehmen hört, ach, da haben wir leider selber nicht die Kapazität, das umzusetzen. Und ich höre bei dir schon raus, das wirst du jetzt delegieren, richtig?

Philipp Beyerlein: Genau, und zwar da kann ich jetzt sagen, okay, weil da habe ich genau dieses Problem, ich muss es ja verstehen, dann einen Fork machen und so, das ist immer so eine Hürde gewesen oder ist immer noch eine Hürde, wenn es heißt, ja, ich würde eigentlich schon gerne das Open Source nehmen, aber ich muss mich drum kümmern, dann nehme ich doch lieber die Lizenz-Variante, die passt vielleicht auch nicht zu 100 %, aber ich habe zumindest jemanden, der sich drum kümmert. Und das ist halt eben diese Spezifikation oder agentische Entwicklung ändert sich das jetzt. Jetzt kann ich sagen, okay, ich nehme diese Open Source, weil die zu 95 % oder zu 90 % passt, und baue den Rest als Spezifikation einfach, definiere ich als Spezifikation und lasse die einfach reinlaufen. Und wenn ein Update vom Master kommt, das ist halt einfach wieder reinlaufen, wieder und wieder, das kostet dann halt vielleicht ein paar Token. Und dann habe ich aber ein Produkt, das so passt, ich muss nicht eben, wie ich jetzt von Null am Anfang, aber es gibt ja schon auch, lassen wir es 70, 80 % sein, die es schon passt. Brauche ich halt den Rest einfach dazu. Und dann wird dieses, und wenn es halt gut ist, vielleicht kann ich ja dann auch einen Pull Request in den Main machen, zum Beispiel Open ID Connect, das sind ja auch Leute, die machen das alles hobbymäßig. Haben die halt in ihrem Umfeld nicht gebraucht. Aber wenn jetzt heißt, eigentlich jeder macht irgendwie Open ID Connect, macht ja auch keinen Fehler, das in den Haupt zurückzuspielen, aber ich habe selber sozusagen meine eigene Customization als unabhängiges Skript oder Spezifikation da stehen. Und da muss ich mich halt nicht mit dieser Architektur so, dass ich mache es als stupide immer und immer wieder da rein.

Gil Breth: Da habe ich mal eine spannende Frage: Wie ist das denn bei Nebu? Wenn wir jetzt Zuhörerinnen haben, die sagen, das finde ich total spannend, ich will mich damit einbringen, habe ich die Möglichkeit, hast du es Open Source gemacht?

Philipp Beyerlein: Ja, ich habe es sogar mehrfach Open Source gemacht, und zwar einmal in GitHub, das ist ja klassisch, aber GitHub hat auch ein zweischneidiges Schwert. Es ist zwar Open Source und bekannt, aber jeder weiß ja, eigentlich gehört es ja Microsoft. Und hier im deutschen Raum hat die Bundesregierung selber vor einiger Zeit Open Code gelauncht, das wird viel von Kommunen genutzt, auch die Ministerien und so weiter haben da mittlerweile viel drin. Da kann man sich einfach ein GitLab-Konto machen, ein GitLab-Projekt anlegen und dort ist es eben auch gehostet. Und die haben sogar auch eine Art Softwareverzeichnis dazu auf dieser Plattform, das ist eigentlich das Coole, wo die sozusagen, die haben ein eigenes Public Code YAML sich ausgedacht, wenn du das in deinem Projekt hast, dann tauchst du eben in diesem Softwareverzeichnis auf. Ich leider noch nicht, ich hatte da noch ein bisschen strukturelle Fehler drin, aber wenn das jetzt mein Feature Branch gemerged ist, dann sollte das da auch auftauchen und dann sehe ich, habe ich da halt einen Überblick über die ganze Software, die da ist, und das ist, ich habe vor einiger Zeit schon mal draufgeschaut, da war echt nichts los, aber mittlerweile ist da echt viel, auch viel so kleinere Sachen von anderen Gemeinden, die ihre Bürger-Apps dort bereitstellen und so weiter. Das ist schon sehr viel, und gerade dieser mit Nebu, der heißt nicht nur ohne Grund Nebu, sondern es kommt von, es hat auch eine kleine Geschichte, und zwar das kommt von, wer Matrix kennt, kennt die Nebuchadnezzar. Und das ist sozusagen das Schiff, das eigentlich die Unabhängigkeit fährt. Ich habe auch ein paar von den Agents, die haben auch Namen aus dem Matrix-Universum, es gibt zum Beispiel das Oracle, das ist mein Matrix-Experte. Der weiß alles über die Matrix und so weiter. Und da eben auch den Namen Nebu, weil es macht ja nur Sinn, wenn ich die Souveränität gesamtheitlich betrachte, und aktuell ist es sogar so, dass ich eher in Open Code reinpushe und dann halt, wenn ich dort fertig bin, dann mache ich halt einen Sync auf GitHub, was halt bekannter ist, aber die Hauptentwicklung habe ich jetzt auf Open Code. Weil dort gibt’s eben coolerweise auch eine CI-Pipeline, kann man einfach GitLab CI benutzen. Es war ein bisschen restriktiver als wenn die anderen Runner nehmen. Das ist halt, aber man könnte auch einen eigenen Runner da einfach registrieren.

Gil Breth: Ich habe mir das auch mal eben notiert, weißt du was? Ich ergreife einfach mal die Gelegenheit, ich will sagen, das hört sich ja eigentlich schon nach noch einer weiteren Folge zu dem Thema an, auch im Zuge des D-Days. Ich spreche einfach mal die Einladung aus, dass wir beide das vielleicht noch mal ein bisschen vertiefen an der Stelle. Stichwort Einladung, ich habe aber auch bei dir gerade rausgehört, das war eine Einladung für die Zuhörerinnen, wer Lust hat, sich einzubringen bei dem Projekt, wir werden es verlinken in den Shownotes, das gerne contributen, richtig?

Philipp Beyerlein: Genau, und wichtig ist: nutzen und Feedback geben. Und davon lebt es ja am Ende. Und man darf es auch gerne Battle-testen. Richtig ist auch, das ist eben auch der Grund, deswegen diese Architektur aus Go und Elixier war ja auch nicht nur die Einfachheit, sondern auch eben, dass ich dort auch mit relativ wenig Ressourcen sehr viel erreichen kann. Ich habe auch so ein bisschen Lasttests drin, das kommt dann jetzt in der Phase 3, da werde ich das mal richtig deployen und richtig mal unter Stress bringen, lokal ist es ja immer ein bisschen witzlos, aber eben sollte ja auch eben dann sehr performant am Ende sein. Was ja auch wieder, sage ich mal, ressourcenschonend, einfacher Betrieb. Das ist auch so ein kleiner bisschen so ein Hinweis für Open Code, weil da ja auch Kommunen schauen, vielleicht ist ja der ein oder andere lokale Kommune, okay, hier habe ich jetzt eben, muss ich nicht die, es gibt zwar einen Stack für Matrix für Synapse oder Element. Da gibt’s auch ein Projekt, aber nicht jede Gemeinde kann halt ein Kubernetes Cluster betreiben, aber vielleicht irgendwo ein Docker. Das einzige, was ich Voraussetzung ist, ist ein Docker Host. Dann kann ich einfach Docker Compose ab und dann läuft es. Auschecken, bauen, starten. Mehr ist es nicht.

Gil Breth: Wunderbar, das klingt sehr gut. Ich denke, wir sind am Ende unserer Folge angelangt und das finde ich auch schön, dass du gegen Ende auch noch mal aufgelöst hast, woher der Name Nebu kommt. Das finde ich klasse. Ich habe es eben schon gesagt, wir werden die ganzen Projekte, das waren ja doch einige in der Folge, in den Shownotes verlinken, sei es Bmat, sei es natürlich das Projekt Nebu selber oder auch Open Code. Und ich kündige auch schon mal an, wir werden natürlich auch zum nächsten D-Day, also zum nächsten Sonntag, zum nächsten ersten Sonntag des nächsten Monats, eine weitere Folge veröffentlichen. Um was es da gehen wird, will ich noch nicht verraten, soll ein bisschen Spannungsbogen aufgebaut werden. Aber wir werden natürlich zeitnah darauf hinweisen und natürlich am ersten Sonntag des Monats das Ganze vorab schon mal als Blogartikel veröffentlichen. Philipp, es hat mir sehr viel Freude gemacht, insbesondere, weil wir natürlich noch zwei Dinge haben, die wir aufgreifen werden: einmal das Back to the Development, das, glaube ich, kann auch noch mal eine ganz spannende Folge ergeben, und das Thema Open Code. Und von daher freue ich mich, wenn wir uns schon bald wieder hören. Und ich hoffe auch, dass es den Zuhörerinnen genauso gefallen hat. Und ich greife noch mal ein: Philipp hat ganz klar eingeladen, Nebu doch zu unterstützen und mal reinzuschauen. Macht das bitte und wir freuen uns aufs nächste Mal.

Diese Zusammenfassung wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Wie können Softwarearchitekten und Entwickler ihre digitale Souveränität stärken, indem sie auf agentenbasierte Entwicklung setzen, um kritische Unternehmenssoftware selbst zu entwickeln, anstatt sich auf kommerzielle oder Open-Core-Lösungen zu verlassen?

Die Herausforderung der digitalen Souveränität in der Unternehmenskommunikation

Gil Breth und Philipp Beyerlein diskutieren die wachsende Abhängigkeit von Unternehmen von externen Kommunikationslösungen wie Teams oder Slack. Philipp hebt hervor, dass diese Tools, obwohl sie den Austausch erleichtern, eine strategische Abhängigkeit schaffen. Er kritisiert, dass selbst Open-Core-Alternativen wie Rocket.Chat oder Mattermost oft kostenpflichtige Lizenzen für essenzielle Unternehmensfunktionen wie Single Sign-On (SSO) oder Compliance erfordern. Diese Abhängigkeit motivierte ihn, eine eigene Lösung zu entwickeln, um echte digitale Souveränität zu erreichen.

„Früher war es halt E-Mail, aber heute ist eigentlich so ein Chat schon wichtig, wenn man da sehr schnell asynchron eben kommunizieren kann, auch weltweit und so weiter. Das hat schon ein Strategie Mehrwert über klassischer E-Mail und Telefon.“

Philipps Entscheidung, eine eigene Chat-Lösung zu entwickeln, entstand aus der Frustration über die mangelnde Souveränität bestehender Alternativen. Er erkannte, dass die traditionelle Softwareentwicklung für ein solches Projekt zu aufwendig wäre, sah aber in der agentenbasierten Entwicklung mit Sprachmodellen eine Chance. Er wollte nicht mehr selbst der Experte für jede Technologie sein, sondern die Anforderungen, Qualitätsziele und Architektur beschreiben und die Code-Generierung den Sprachmodellen überlassen.

BMAT und die Rolle des Architekten in der agentenbasierten Entwicklung

Philipp erläutert, wie er das BMAT-Framework (Build More Architected Dreams) nutzte, um sein Projekt Nemo zu realisieren. BMAT bietet eine Sammlung von Agenten-Skills, die den Kontext des Agenten mit spezifischen Fähigkeiten und Skripten füllen. Im Gegensatz zum „Wipe Coding”, bei dem der Agent die meisten Entscheidungen trifft, bleibt der Mensch bei BMAT der Product Owner und Architekt. Die Agenten formalisieren die Vision in Spezifikationen, aber die finalen Entscheidungen liegen beim Architekten.

„Ich muss nicht mehr selbst der Experte in irgendwelchen Messaging Technologien oder sowas sein, sondern ich kann die Anforderung beschreiben, die Qualitätsziele beschreiben, die Architektur beschreiben und es reicht und dann die die Übersetzung von dem ganzen Code, das kann ich machen lassen, einfach machen lassen.“

Philipp beschreibt, wie er mit einer groben Produktvision startete und diese mithilfe von BMAT-Workflows und Kreativmethoden verfeinerte. Er wählte bewusst Technologien wie Go und Elixir, die von LLMs gut verarbeitet werden können und wenig Framework-Overhead haben, um die Komplexität zu reduzieren. Insbesondere die Entscheidung für Elixir half ihm, das Problem der Nachrichtenbroker zu umgehen und eine effiziente, skalierbare Lösung zu schaffen, ohne auf externe Lizenzen angewiesen zu sein.

Enterprise-Features und die Kosten-Nutzen-Rechnung von Nemo

Philipp beleuchtet die Enterprise-Features, die er in Nemo integriert hat, um es zu einer vollwertigen Alternative für Unternehmen zu machen. Dazu gehören OpenID Connect für Single Sign-On, ein Compliance-Flow mit Vier-Augen-Prinzip für die Auskunftsfähigkeit über Chat-Verläufe und Skalierbarkeit für den Betrieb in größeren Umgebungen. Er verzichtete bewusst auf Ende-zu-Ende-Verschlüsselung, um die Compliance-Anforderungen zu erfüllen, und auf Federation, da diese für einen geschlossenen Unternehmenskontext nicht zwingend erforderlich ist.

„Das sind halt Features, die gibt’s halt wenn dann eher eben auch in den Enterprise oder in den Lizenzpflichtigen. Und dann noch kommt als dritter Punkt Skalierbarkeit.“

Die Kosten für die agentenbasierte Entwicklung sind hauptsächlich durch den Token-Verbrauch der LLMs bedingt. Philipp schätzt, dass ein monatliches Kontingent von 100 bis 200 US-Dollar ausreicht, um viel zu erreichen. Er argumentiert, dass diese Investition im Vergleich zu den Kosten für ein traditionelles Entwicklungsteam oder den Lizenzgebühren für kommerzielle Produkte gering ist. Die agentenbasierte Entwicklung ermöglicht es, komplexe Probleme effizient zu lösen und gleichzeitig die digitale Souveränität zu wahren.

Nachhaltigkeit und Zukunftsperspektiven von Nemo

Philipp betont die Bedeutung der Spezifikation und Transparenz für die Nachhaltigkeit von agentenbasiert entwickelten Projekten. Da jede Story, jeder Agent und jede Architektur-Entscheidung in BMAT dokumentiert ist, kann jeder, der Zugang zu einem Cloud-Agenten hat, das Projekt weiterentwickeln. Er empfiehlt, von Anfang an test- und behavior-getrieben zu entwickeln und spezialisierte Agenten für Fachlichkeit und Sicherheit einzusetzen.

„Da kommt wieder der die die Spezifikation zu tragen und zwar was mir von vorne rein wichtig war, ich wollte nicht verstecken, dass ich es agentisch entwickelt habe.“

Für die Zukunft von Nemo plant Philipp die Integration von Medien-Handling, die Erweiterung der Admin-Oberfläche um Raum- und Benutzerverwaltung sowie die Schaffung von „Spaces” für Projekte. Langfristig denkt er über eine Integration der Admin-Oberfläche in den Chat selbst nach und die Entwicklung eines eigenen Clients basierend auf Fluffy Chat, um vollständige Kontrolle über Branding und Features zu haben. Er sieht in der agentenbasierten Entwicklung eine Möglichkeit, die „Make or Buy”-Entscheidung zu revolutionieren, indem Open-Source-Projekte, die zu 90–95 % passen, durch agentengenerierte Spezifikationen ergänzt und angepasst werden können. Nemo ist Open Source auf GitHub und Open Code verfügbar, um die Zusammenarbeit und Weiterentwicklung zu fördern.