# Agentic Engineering: Building Sovereign Software with B-MAT

**Podcast:** INNOQ Podcast
**Published:** 2026-06-05

## Transcript

Herzlich willkommen zu einer neuen Folge des InnoQ-Podcasts.
Und dieses Mal geht es wieder um den D-Day, den sogenannten Digital Independence Day.
Dabei handelt es sich um eine Initiative, die am ersten Sonntag des Monats Rezepte vorstellt, wie man seine digitale Souveränität verbessern kann.
Und wir von InnoQ möchten auch unseren Beitrag dazu leisten und werden diesen Monat dazu das Projekt NEMU vorstellen, das mein Kollege Philipp Beyerlein, der hier heute mit mir als Gast ist, ja, Selfmade, Souveränität bezeichnet hat.
Lieber Philipp, herzlich willkommen.
Vielleicht magst du dich aber kurz vorstellen und gerne auch dein Projekt.
Ja, hallo Jill.
Ich bin Philipp Beierlein, bin seit sieben Jahren Senior Consultant bei der Firma EndoQ, habe dort mich nie mit AWS-Betrieb in den vergangenen Jahren beschäftigt, bin auch dann mittlerweile wieder in die Solution-Architektur gegangen und seit zwei Jahren beschäftige ich mich mit.
mehr mit Souveränitätsthemen, also nicht mehr ausschließlich Betrieb auf AWS, sondern eben Alternativen, auch wie man mit dem Risiko, mit der Abhängigkeit und so weiter umgeht, habe ich schon diverse Beiträge verschafft oder erschaffen.
Und in den letzten Wochen kam immer mehr im KI, agentische Entwicklung hinzu und es hat mich schon länger kam die Überlegung, kann man das nicht nutzen, um seine Souveränität eben zu steigern.
Und parallel kam auch noch zum agentischen Engineering gibt es, ja, sag ich mal, mehrere Richtungen.
Einmal das Vibe-Coding, hat der eine oder andere bestimmt schon gehört.
Ich tippe einfach irgendeine Idee ein und lasse dann alles komplett einfach machen.
Und das hat mir bisher nicht so...
Weil ich bin eher, komme auf die Architektur, ich will da eigentlich mehr Struktur, mehr Kontrolle, Qualität, Tests und so weiter.
Und das hat mir bei Vibe-Coding immer gefehlt.
Und da habe ich schon von Anfang an sehr viel in Planung investiert gehabt, wenn ich was gemacht habe mit KI.
Also immer einen Markdown erzeugen, wo ich der ganze Plan, was alles drin ist.
Und zum Glück wurde das mittlerweile formalisiert in Sinne von SPIC-getriebenen Entwicklung.
Hat das Ganze einen Namen bekommen.
Und ich habe mich jetzt in den letzten Wochen intensiver mit dem STD-Framework BMAT, Build More Architected Dreams ausgesprochen, beschäftigt.
Und wenn man das nun mit der Bestimmung digitaler Souveränität vermischt, öffnen sich plötzlich ganz neue Möglichkeiten.
Und zwar das Produzieren von Software und Softwarelösungen ist jetzt mittlerweile ganz einfach geworden.
Wenn ich jetzt ein Wort schreiben kann, kann ich es auch umsetzen mit Hilfe von eben speckgetriebener Entwicklung.
Und es gab schon lange, also eines der wesentlichen Abhängigkeiten, die momentan so Unternehmen oder auch Vereine, generelle Akteure haben, ist das Thema Kommunikation und Chat.
Da gibt es eben auf...
der Unternehmensseite, da gibt es halt so Klassiker, Teams, Slack und so weiter.
Und es sind halt, sag ich mal so, die Chat-Kommunikation am Unternehmen ist schon strategisch wichtig geworden.
Früher war es halt E-Mail, aber heute ist eigentlich so ein Chat schon wichtig, weil man da sehr schnell asynchron kommunizieren kann, auch weltweit und so weiter.
Das hat schon einen strategischen Mehrwert über klassischer E-Mail und Telefon.
Wenn man da jetzt mal eben Automativen sucht, bei Google, zu Slack oder Teams, es gibt schon, kommt man eigentlich dann zu anderen Playern wie Rocket Chat, Mattermost oder Matrix.
Und die sind an sich von der Strategie her eigentlich Open Core.
Also sie haben immer eine Community-Version, aber sobald ich auf, als Unternehmen irgendwelche Unternehmensfeatures haben will, Steht es meistens so, es gibt so eine klassische Tabelle mit FU-Kreuzchen drin sind.
Dann lese ich für SSO, irgendwelche DSGVO-Sachen und so weiter.
Da brauche ich immer eine Lizenz.
Muss ich dann eine Lizenz kaufen.
Und dann ist es zum Teil, bei Jira hat man es jetzt erlebt, da gibt es auch vielleicht eine On-Premise-Version, aber eigentlich wollen sie das nicht.
Sondern die wollen eigentlich, dass man das als Software-so-Service nutzt.
Deswegen sind dann die On-Premise-Lösungen dann auch noch so gebaut, dass ich sie eigentlich schwer betreiben kann.
Und das hat mich gestört und gesagt, das kann doch nicht sein, dass man, wenn man sich dann mal souverän aufstellen will, es gibt Alternativen, aber so richtig souverän fühlt sich das nicht an, weil ich am Ende dann doch wieder eine Lizenz brauche oder andere Abhängigkeiten habe, da kann ich auch gleich bei Slack bleiben.
Da bringt mir das einfach überhaupt nichts.
Da habe ich nur...
eine andere Rechnungsadresse auf der Rechnung.
Aber die Abhängigkeit an sich zwischen meinem und dem Human und dem anderen bleibt ja gleich.
Und wenn man das alles zusammenbaut, bin ich auf die Idee gekommen, wieso nehme ich nicht einfach, brauche ich das nicht einfach selbst eine Alternative?
Ja, das finde ich total spannend.
Ich habe letztes Jahr noch mit einem CTO darüber gesprochen, als wir ein bisschen über die Abhängigkeit in seiner Softwarelandschaft gesprochen haben.
Und das war von mir auch ein Erkenntnis, als er sagte, oder einer meiner größten Paints ist eigentlich, wenn morgen Teams nicht mehr funktioniert.
Da wurde mir erst mal bewusst, das ist so ein Commodity.
Wir nutzen es tagtäglich.
Das ist so selbstverständlich, ob das Slack ist, ob das Teams, ob das Zoom ist.
Aber wenn das nicht mehr da ist, dann steht im schlimmsten Fall direkt das ganze Unternehmen irgendwie erst mal still.
Und als ich dann deine Idee gesehen habe, habe ich mich...
Das war für mich so ein Augenhöf, wo ich dachte, klar, man guckt immer nach Alternativen, wir kennen das alle, hast diese Matrizen mit Feature-Vergleich, Preis-Vergleich, aber auf die Idee zu kommen, zu sagen, ich mache das an der Stelle selber, weil das für mich ein so zentrales Werkzeug ist, das war für mich irgendwie ein neuer Gedanke an der Stelle.
Da würde ich gerne nochmal nachfragen.
Und wann war dieser Punkt, dass du gesagt hast, ich mache das jetzt selber, ich baue das selber?
Also hast du dir nicht volle Alternativen angeschaut oder war für dich direkt von vornherein klar, ich habe da mal, ich sage mal auf gut Deutsch gesagt, ich habe da Bock drauf, mal so ein Chat, so ein Kommunikations-Client zu bauen?
Also den Gedanken, das selber zu machen, hatte ich schon länger, als ich mich mit generellen Alternativen zu Teams und Slack beschäftigt habe.
kommt man ja automatisch eben zu Matrix, Matamoros, RocketChat als Alternativen aus, die da auch zumindest on-premise betrieben werden können.
Aber ich habe eben dieses, da muss ich dann wieder, wenn ich das ausprobieren will, als Unternehmen, da muss ich da irgendeinen Vertriebler anrufen und so weiter.
Das ist alles so lang und so zäh.
Und dann habe ich im Hinterkopf gedacht, eigentlich müsste man das selber entwickeln, zum Beispiel Matrix.
ist ja 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 sowas komplett zu bauen, das ist schon eine Herausforderung.
Also die wissen schon, dass ein Chat bauen ist jetzt nicht einfach.
Also das setzt man sich nicht einfach so mal hin.
In der traditionellen Softwareentwicklung 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 schon so die Idee, wieso mache ich das nicht einfach mal mit agentischer Entwicklung?
Vibe-Coding war mir da zu riskant, zu unstrukturiert.
Weil ich ja schon, wenn ich sowas mache, habe ich ja schon, ich sage mal so, es ist ja kein Hobby, also kein Spielzeugprojekt, wo ich jetzt mal irgendwie so ein Hello World oder sowas, sondern die Anforderung ist schon komplex an so ein Chat, vor allem wenn ich das als Unternehmen strategisch, also die Firmen, die dafür Geld verlangen, die verlangen ja auch nicht ohne Grund dafür Geld, also 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 sowas sein, sondern Ich kann die Anforderungen beschreiben, die Qualitätsziele beschreiben und die Architektur beschreiben und es reicht.
Und dann die Übersetzung von dem ganzen Code, das kann ich machen lassen, einfach machen lassen.
Ich finde das total schön, weil was ich da rausführe, ist, du hast mehr Lust darauf gehabt, es deinen Agenten zu erklären, statt dem Vertriebler, was du möchtest.
Also du bist so ein bisschen den Man in the Middle oder den Woman in the Middle entgangen.
Und du hast eigentlich direkt mit der Maschine endlich mal gesprochen.
Jetzt hast du eben gesagt, das Was war für dich eigentlich schon irgendwie klar, dass du da Lust hast, das zu machen.
Ich würde gerne noch ein bisschen über das Mie sprechen.
Also kannst du nochmal zum Thema BIMAT ein bisschen ausholen und das nochmal erklären, vielleicht auch konkret anhand eines Projekts.
Also was ist das nochmal 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 NEBU am Ende des Tages dann noch zu bauen?
Also ich habe zuerst ein paar kleine Experimente mit BIMAT gemacht.
An sich vom Grundkonstrukt her eigentlich eine Sammlung von Skills, Agentenskills, die eben sozusagen den Kontext eines Agenten mit bestimmten Fähigkeiten füllt.
Und da kann ich in dem Skill, kann ich halt sowohl Soft Skills reinschreiben, wie zum Beispiel irgendwelche Entwicklungsstandards, aber auch, ich kann da Skripte reinpacken, ich kann dort Templates reinpacken.
Eigentlich so alles möglich, damit ich das dem Agenten nicht jedes Mal neu erzählen muss, sondern es ist dort einmal drin.
Und das kombiniert BMAT eigentlich immer.
Die haben einen Skill, ein Skillset und dann nutzen die auch eine vorgefeste Schablone, um das, was die Skills erzeugen, abzuspeichern.
Und die Skills sind so gemacht, dass der Agent nicht selber fährt, sondern eher, ist sozusagen der Zuarbeiter sozusagen, er übernimmt jetzt nicht meine Entscheidungen, sondern ich sage dem meinen Willen, er formalisiert es eben in Spezifikation und dann kann ich zwar schon Feedback und so weiter einarbeiten, aber ich, er ist eher so wie ein Interviewer, immer sozusagen wie wenn mich jetzt ein anderer Entwickler fragen würde, was willst du denn jetzt tun und ich sage dem, 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 B-Mart.
Gegenüber jetzt eben, wenn ich jetzt Vibe-Coding mache, da schreibe ich meine Idee rein und dann entscheidet er einfach das meiste.
Also Architektur, Qualität und so wird halt einfach nach.
Er entscheidet es ja nicht einfach wie, sondern an 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 BIMAT ist das eben umgedreht.
Wie konkret war deine erste Produktvision?
Also ich meine, wie genau muss ich es machen?
Hast du einfach nur gesagt, ich möchte Chatlösung oder hast du es ein bisschen griffiger gemacht?
Wie viel bist du denn gestartet?
Da bietet Beamert mehrere Einstiegsmöglichkeiten.
Das sind eigentlich an sich einzelne Schritte.
Und du kannst sozusagen, der allererste Schritt reicht, wenn du eine Produktvision hast.
Das steht dann so ein PAD-File, nennt sich das.
Das ist ein Produktbeschreibungszeiten.
Und selbst für die Erstellung dieses PAD-Files hat Beamert einen eigenen Workflow innen drin mit verschiedenen Kreativmethoden, was die haben.
Chaos-Methode oder verschiedene Hütemethode.
Da haben die so gängige Kreativmethoden verskriptet als Skill und die kann man dann nutzen.
Oder eben der hat auch eigene verschiedene Agenten.
Immer parat für verschiedene Tätigkeiten, für Entwickler, für Produktdesigner, für Tester, für Sicherheit, für alles mögliche.
Hat er so Agents, Sub-Agents?
Und die kann ich dann zum Beispiel auch zu einer Partyrunde einladen und dann diskutieren die über die Lösung.
Und so kommt man dann immer weiter und kann man sich auch kreativ, wenn man jetzt am Anfang vielleicht nur einen Satz hat, wie zum Beispiel, ich will einen eigenen Matrix kleinbauen, kommt man dann immer weiter, immer tiefer zu einer richtigen, ausgereifenden Produktvision.
Was ich damals zum Beispiel wusste, ich will eben einen Matrix nutzen, weil ich mir dann kein Protokoll selber ausdenken muss.
Das Protokoll gibt es schon.
verschwinde ich nicht viel Zeit in Protokollerstellerei und ich habe ja schon Clients, die damit funktionieren.
Dann wollte ich eben sowas wie, ich will eigentlich möglichst wenig zusätzliche Infrastruktur haben, möglichst wenig Abhängigkeiten.
Da kam schon die erste Falle bei so einem Chat, weil das machen natürlich die meisten Chatbeispiele, die man zum Internet finden, nutzen irgendeinen Broker wie Redis oder irgend sowas und Überlassen dann dieses Zustellen der Nachrichten dem Broker.
Publish und Subscribe ist ja klassische Broker-Modell.
Aber da ist ja schon wieder die nächste Falle bei Redis.
Um ein Redis gut betreiben zu können, brauche ich auch wieder eine Lizenz.
Also in meinem ersten Wurf war das sogar mit drin, dass ich eine Art Go-Gateway habe.
Weil Go ist halt einfach schlank.
Ich habe mir jetzt bewusst Technologien ausgesucht.
Dort, wo ich sage, okay, 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.
Und dann war natürlich klar, eine Sprache zu finden, die sehr flach orientiert ist, wo ich wenig Frameworks brauche, wo Web drin ist.
Und dann musste ich aber jetzt eben noch das...
Broker-Problem lösen, weil Broker, ich will eben keinen Redis, weil Redis Cluster betreiben ist auch Wiederaufwand.
Weil da kommt wieder eine Produktvision dazu.
Das soll ja auch so sein, dass es jemand betreiben kann.
Aber sieht man sich, die jetzigen, von Matrix gibt es ja auch eine Community Edition von Elements oder den Elements Pro Server.
Das ist ein richtiger Brummer.
Also da muss man fünf, sechs Komponenten betreiben und Da ist man eigentlich schon ohne Kubernetes oder so, für kleinere Betriebe ist es fast unrealistisch, das zu betreiben, weil die halt dann Redes, Datenbank, drei, vier Anwendungen, dann irgendeinen Identity Server und alle möglichen Zeugen muss man da betreiben.
Und ich hatte eigentlich die Idee zu sagen, das muss eigentlich so mit den klassischen drei, vier Mann Admin-Team irgendwie machbar sein, das zu betreiben.
Und da kam eben habe ich mich dann erinnert, vor langer, langer Zeit, ich hatte schon immer mal so auf meiner Bucketlist, Erlang auf der Liste.
Weil die Erlang ist ja halt sehr viel mit Messaging, kommt aus der SMS-Welt und so weiter.
Und da hat mir dann das LLM auch auf die Sprünge geholfen, weil ja WhatsApp zum Beispiel nutzt intern auch einen Erlang-Elixier-Stack.
Und das ist ja erprobt.
Und die haben das lange mit ganz wenig Hardware ganz viel geschafft damit, weil das Erlang...
beziehungsweise Elixir so effizient mit dieser Nachrichtenverarbeitung gehen kann, weil das einfach Basistechnologie im Körnel ist von Elixir und Erlang.
Und damit habe ich dann eigentlich diesen Bedarf eines Brokers komplett weg.
War komplett weg.
Nur weil ich jetzt gesagt habe, okay, ich entscheide mich für die richtige Technologie.
Ich kenne selber zwar keine Erlang und so weiter, muss ich auch nicht können.
Aber ich kann der Ellen sagen, das ist jetzt das Bessere und damit löse ich die Abhängigkeit und dann macht er das.
Sehr schön.
Ich würde gerne nochmal ganz kurz ein, zwei Schritte zurückgehen.
Also erstmal, ich merke schon eine Begeisterung und ich hoffe, dass das kommt auch so bei unseren Zuhörerinnen an, weil ich finde es schon schön, wenn man nämlich am Ende der Episode jeder, der heute...
und werdet ihr heute zuhört, in der Lage ist, vielleicht das auch selber einmal durchzweck zerstieren.
Und deswegen möchte ich nochmal bei ein paar Sachen nachhaken.
Jetzt hast du ja eben mit jemand 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 dann dabei zugeschaut hast, was sie so diskutiert haben.
Ist das Team natürlich die eine Sache, aber schauen wir nochmal ein bisschen auf die Tools.
Also was für Tools sind da zum Einsatz gekommen oder welche LLMs hast du eingesetzt?
Kannst du das auch mal ein bisschen erklären?
Ich habe dafür jetzt wesentlich Cloud und die aktuellen Cloud-Modelle Sonnet und Opus genommen.
BMAT selbst ist agnostisch, die unterstützen auch die GPT-Modelle.
Als Tool habe ich eben Cloud-Code und Cloud-Code am besten damit integriert.
Aber man muss auch sagen, dass die ersten B-Mod-Versionen waren halt auch sehr stark auf Cloud fokussiert, auf Cloud-Code.
Also von der Interaktion mit dem Agenten war das besser.
Ich habe es auch mal am Anfang mit Codex ausprobiert, aber da hat es nicht so ganz so funktioniert mit diesem, weil Codex hat, ich weiß nicht, ob es das mittlerweile ist, aber damals hatte Codex nicht so diesen Hook-Mechanismus, also das Sub-Pages oder Sub-Prozesse.
aktiv wieder zurückkommen und dieses Hook-Mechanismus braucht BMAT für dieses Agenten-Party-Modus, damit er eben sagen kann, hier, da startet der einzelne Subagent mit den verschiedenen Rollen und gibt denen dann verschiedene Schnipsel und die bewerten das dann.
Und da, weil das ist so ein kleiner Grundmuster, das sich bei BMAT immer durchzieht, gehen bei vielen Sachen davon aus, dass du immer mit einem neuen Kontext startest.
Das sagt er auch immer wieder, dass du jetzt den Kontext lernen sollst, wenn du jetzt 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 kramt er halt wieder in irgendeinem Kontext, in seiner Memorierung und folgt nicht dem, was du vielleicht spezifiziert hast.
Ja, okay.
Spannend.
Ich finde das so faszinierend, weil du hast jetzt das Team, du hast irgendwie deinen Toolstack und da stellt sich mir dann immer die Frage die ganze Zeit dabei, welche Rolle spielst du denn?
Also du als Mensch doch darin.
Also wo greifst du ein?
Wo lässt es einfach laufen?
Wo sagst du mal, ich ändere vielleicht auch den Toolstack oder passt irgendwelche Entscheidungen an?
Also gab es für dich so ein paar Ristiken, wo du festmachen konntest, da muss ich jetzt mal irgendwie eingreifen?
Ich bin immer noch sozusagen der Lenker am Ende.
Man kann sich das auch vorstellen wie ein Auto.
Auto macht ja auch ein Auto mit Automatik und so weiter, macht auch ganz vieles.
Du musst dir jetzt nicht über die Zündzeitpunkte im Motor oder sowas Gedanken machen, das macht ja alles für dich.
Sondern du musst dir schon überlegen, wo fahre ich hin, bin ich innenperformant unterwegs.
Was ich zum Beispiel am Anfang habe ich Niemand hat da auch schon so, wo ich dann in die Umsetzung gegangen bin, dass ich eben eine Story erstellen kann, dann aus den Story den Code, dann Review.
Und es war relativ einfach.
Hat am Anfang auch ganz gut funktioniert, so für den Ramp-Up von dem ganzen Projekt.
Aber dann wurde es irgendwann kompliziert.
Und gerade das Matrix-Protokoll selber hat so ein paar Fallstricke, wie...
Also die haben eine API, wo ich was reinschicken kann und dann hat der Client so einen Sync-Endpoint, wo Events zurückkommen.
Und dieses Sync-Event-Verhalten, da habe ich lange, also ich habe dann eigentlich die Rolle des Abnehmers, des Reviews am Ende sozusagen, der Endkunde sozusagen den Endkundentest gemacht.
Ich habe einfach den Matrix-Klein gestartet, der dagegen dann einfach.
geschaut, ob ich chatten kann, ob ich mich einloggen kann und solche Sachen.
Und dann habe ich halt dem Feedback gegeben und am Ende gesagt, das ist falsch.
Und irgendwann hat es mich dann, weil er dann immer wieder den Fehler nicht gefunden hat, habe ich mir gedacht, jetzt muss ich eigentlich so wie ein klassisches Softwareprojekt, wenn ich auch Fehler habe, was mache ich dann?
Was habe ich dann für Strategien?
Okay, ich habe die Teststrategie erhöht.
Es gab von BMAT, kam dann irgendwann ein Testautomatisierungsmodul.
Das habe ich mit eingebaut.
Ich habe mir dann so eine Mini-Pipeline.
Skill gebaut, der halt die Schritte und dann habe ich halt die in die Testabdeckung reingemacht, in Teststrategien reingemacht und so habe ich das halt dann weiterentwickelt.
Irgendwann kam dann auch das Thema, ja Security muss man ja auch, weil wenn ich sage, okay, also so Matrix-Server, das hat schon in der Community eine hohe Messlatte, sage ich mal so.
Da darf man sich, Security muss sich keine Patze erlauben, sonst mal raus.
Und dann habe ich halt einen eigenen Agent, Cassandra, zum Beispiel mit hinzugebaut, die mir dann im Revu oder immer wieder die Pipeline aktiviert, wenn es um Security-Themen geht.
Da habe ich dann explizit gesagt, die Features soll OVASP-Fähigkeiten haben und so weiter und eben da auch kritisch sein.
Nicht panisch, aber kritisch.
Da kann man denen so ein bisschen Charakter geben, den Agenten, wie die arbeiten sollen.
Dann hatte ich dann irgendwann so die Sicherheit, okay, Jetzt habe ich einen, der kümmert sich um die Security.
Und dann eben habe ich immer wieder, kam dann Fehler mit dem Matrix-Protokoll raus.
Und das war mir dann auch irgendwann, das LM hat zwar Matrix-Einträge bekommen, aber so diese, gerade dieses Event-Rückspielung und so weiter, das war schwierig.
Und dann habe ich mir gedacht, jetzt mache ich mir nochmal einen anderen Agenten, der sich nur mit der Fachlichkeit des Matrix-Protokolls auskennt.
Und der soll dann entsprechende Reviews geben und so weiter.
Und so hat sich das dann eigentlich immer weiterentwickelt, mein Entwicklungs-Set.
Und das ist dann eigentlich die Aufgabe.
Ich muss jetzt nicht so den Code machen, aber ich bin trotzdem dafür verantwortlich, dass ich aus meinen Produktideen funktionierenden Code am Ende schaffe, der qualitativ hochwertig ist.
Und wenn ich sage zum Beispiel, ich will compliance-sicher sein und so weiter, dann habe ich ja schon Qualitätsziel, auf die ich hinarbeiten muss.
Und das muss ich kontrollieren.
Das muss ich machen.
Und weil ich, ich habe zwar den Code jetzt nicht so viel gesehen bisher, bin ich ehrlich, aber das, was ich gesehen habe, ich habe halt am Anfang schon den Trick gemacht, ihm gesagt, er soll möglichst flach alles machen zum Beispiel.
Es gibt kein Entity-Modell in meinem Code zum Beispiel, weil ich habe ja, mein Entity-Modell steht ja in meinen SQL-Skripten drin.
Und das nutzt ja der Entwicklungsagent, nutzt permanent das, der weiß das SQL-Schema, also kann auch die entsprechenden SQL-Statements schreiben.
Ich habe kein Framework, irgendwas, was ich verstehen muss, sondern ich habe eigentlich nur den API-Request und das entsprechende SQL-Statement dazu.
Das kann ich super einfach selber lesen.
Da brauche ich keinen, das kann ich jederzeit reingucken und verstehe, was er tut.
Ich muss da einmal einhaken, weil da stecken ja eine Menge Entscheidungen drin.
Du bist eben ja 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?
Nee.
Nee.
Okay.
Mir hat es interessiert, dass die Tests funktionieren und dass die Fachlichkeit funktioniert.
Das interessiert mich.
Ja, aber was ich daraus höre, sind ja auch eine Menge Entscheidungen und zwar als tektonischer Art.
Also da würde mich natürlich schon interessieren, hast du dich vorab 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, sage ich mal, aufgebaut und eingefügt hast?
Also das sind ja schon weitreichende Entscheidungen.
Wie bist du denn da vorgegangen, was gerade diese, ich nenne es mal weitreichende, als Tipu-Entscheidungen angeht?
Ich habe mir da, also was so Struktur angeht, das stand sehr, eigentlich das zweite Datei, die immer nach diesem PRD-File ist, das Architekturfile, was man da anlegt, wo die Architektur drin steht.
Und ich wollte ja absichtlich etwas schaffen, das ein LLM gut bauen kann.
Und dann macht es ja natürlich Sinn zu sagen, ich optimiere den Code jetzt nicht für die Menschen, sondern für das LLM.
Und ich habe eben in anderen Projekten schon versucht, eben mit zum Beispiel bei Java-Projekten und so weiter.
Und da sind die immer mit zum Beispiel Vererbung.
Vererbung ist tödlich für einen LLM, weil der muss so viel Wissen aufbauen, um zu verstehen, was passiert.
Und das ist halt sozusagen, ich wollte einfach mal das andersherum machen, als wir Menschen das machen, sondern für einen LLM das machen.
Wenn wir mal ehrlich sind, diese ganzen Frameworks wie Spring und so weiter, die machen ja eigentlich nur, auch wieder nur einen HTTP-Request in ein SQL-Statement übersetzen.
Was anderes machen die ja nicht.
Mit ganz viel Code dazwischen.
Und wieso macht das das?
Haben wir das dazwischen?
Weil wir Menschen natürlich, wir haben gegrenzte Kapazität im Kopf.
Wir können nicht eine Million Tokens auf einmal im Kopf verarbeiten.
Und dann vergessen wir was.
Und deswegen brauchen wir immer diese Sicherheit, hat man sehr viel auf den Compiler abgewetzt, dass der Compiler einem sofort sagt, okay, da habe ich mich jetzt vertippt, dort habe ich jetzt falsch gemacht, dort passt das nicht in mein Modell und so weiter.
Haben wir diesen sozusagen Kontextschutz dem Compiler nach und nach aufgedrängt.
Aber das bräuchte er bei dem LLM nicht.
Der hat das ja im Kopf, ich habe das in meiner Speck, ich habe das ja niedergeschrieben.
Der respektiert das ja, was ich da niedergeschrieben habe.
Und deswegen kann ich halt einfach sagen, okay, mach den Code so flach wie möglich, baue keine künstlichen Hierarchien ein, nur da, wo es halt irgendwann macht es Sinn, ein bisschen zu modularisieren.
Wenn ich sage, okay, ich habe jetzt hier zum Beispiel OpenID Connect Sachen, wo ich sage, okay, ich habe jetzt hier Filter, die für mehrere gelten, hier so aspektemäßig.
Das kann man schon machen, aber sonst ist er halt sehr flach und ich nütze bewusst auch möglichst wenig.
Frameworks zu machen, weil ich kann es halt einfach selber machen lassen.
Und das war von Anfang an eigentlich, hatte ich auch so eine Idee im Kopf schon länger, wieso macht man das nicht eigentlich so und löst sich einfach mal von diesem Code.
Bisher, wenn ich mit Kollegen spreche, die hängen noch immer sehr am Code.
Und ich sag eigentlich, ich muss eher am Test hängen.
Der Test ist meine verskriptete Spezifikation sozusagen am Ende.
Und wenn der Test funktioniert, ist mir doch der Weg dazwischen nicht mehr so wichtig.
Ich weiß, der Test funktioniert.
Und deswegen investiere ich doch mehr in die Spezifikationen, in die Tests als in den Code.
Und wenn ich den Code einfach halte, bewusst einfach halte, dann kann ich den auch einfach jederzeit lesen.
Ich habe Ihnen jetzt nicht gesagt, er soll nur Variable mit zwei Buchstaben benutzen.
Das macht er nicht, aber ich sehe halt sozusagen meinen...
einen treueren Domain in Code übersetzt, das gibt es nicht.
Da fängt die plötzlich an und schreibt irgendwas anderes rein in den Code, als wie er seinen Kontext hat.
Das macht er halt auch nicht.
Das stellt sich natürlich die Frage, also wie viel Vertrauen gebe ich da rein, wie viele Erfahrungen habe ich auch, das bewerten zu können?
Ich finde die Gedanken gegen den Direktor ganz spannend an der Stelle.
Ich würde aber gerne nochmal auf Nebo selber zurückkommen.
Und zwar diese Lösung, die du gebaut hast.
Wenn wir das jetzt nochmal ein bisschen, du hast ja eingangs von Enterprise-Featuren bei Kostenpflichten oder kommerziellen Alternativen darüber gesprochen.
Also welche Enterprise-Feature hast du denn jetzt im Detail da eingebaut?
Also was steckt in dem Nebo drin, dass es Enterprise-fähig machen könnte?
Es gibt ein paar Dinge, die immer bei Enterprise gesperrt, also immer kostenpflichtig sind.
Das ist einmal, dass ich die Möglichkeit habe, bei OpenID Connecter das English-Send-On zu machen.
Man muss mal sagen, es gibt zwar in der Community mittlerweile auch die Möglichkeit, OpenID Connect-Server ranzumachen, aber es gibt jetzt nicht so eine richtig coole, tolle Rollenrechte-Konzepterei da drin.
Es ist halt einfach eine weitere Authentifizierung.
Aber so richtig Autorisierung gibt es da nicht drin.
Und das war für mich von Anfang an klar.
Eigentlich ohne OpenID Connect, das muss standardmäßig drin sein.
Dann brauche ich das Thema Compliance, weil das ist so der große Unterschied zu den anderen Matrix-Lösungen, die es so gibt.
Die sind dafür da, dass ich einen Matrix-Server treibe und für eine unbekannte Gruppe an Leute.
Ich bin sozusagen der Betreiber eines Chat-Servers.
Aber aus Unternehmen-Sicht ist es ja anders, sondern es ist ja alles, was ich mit diesem Server kommuniziere, gehört ja auch der Firma.
Also muss es einen Compliance-Support geben.
Und da habe ich zum Beispiel, Matrix selbst hat ja auch eine Ende-to-Ende-Verschlüsselung und die habe ich bewusst erst mal rausgelassen.
Die wird vielleicht kommen, wenn es...
Irgendjemand sagt, er will es trotzdem haben, aber wenn ich natürlich als Firma einen Chat zur Verfügung stelle meinen Mitarbeitern, muss ich jederzeit aufkunftsfähig sein, was über diesen Chat kommuniziert wurde.
Dass wenn zum Beispiel jemand ein Verbrechen über dieses System plant, dass ich das auf staatsanwaltliche Anordnung ausgeben kann, bei Bedarf.
Und so ist es zum Beispiel, es überwiegt diese Ende-to-Ende-Verschlüsselung in dem Fall.
Deswegen habe ich dort von Anfang an jetzt auch in dem MVP schon ein Compliance-Flow, dass ich ein Vier-Augen-Prinzip habe, wo ich mir sagen kann, ich würde gerne von folgenden Teilnehmern folgende Chat-Verläufe raushaben und dass ich dann eher auf Signatur setze, dass die nachdenklichen signiert sind, dass dann auch dieser Compliance-Report entsprechend signiert ist.
Und das sind halt Features, die gibt es halt, wenn dann eher eben auch in den Enterprise oder in den Lizenzpflichtigen.
kommt das dritte Punkt, Skalierbarkeit.
Die richtige Skalierungsstrategie gibt es auch meistens nur gegen Lizenz.
Weil sozusagen als Community habe ich vielleicht kein Lizenzproblem, wenn ich halt ein bisschen Hardware, 150 bis 100 Leute kann ich ja prinzipiell machen ohne Skalierung.
Aber wenn ich jetzt sage, okay, ich habe jetzt hier plötzlich 10.000 oder ein Tausenderbereich oder mehr, dann brauche ich schon Skalierung, Ausfallsicherheit geht es dann eher um Skalierung, sondern dass ich einen Cluster habe, wo ich dann eben, wenn einer ausfällt, eben tauschen kann, wo ich rolling-updates machen kann und so weiter.
Und das waren halt alles Features, die eben hinter der Lizenz versteckt sind.
Wobei ich mir halt denke, das ist ja aus Architektursicht, es ist ja heute kein Hexenwerk mehr, etwas skalierbar zu bauen, OpenID Connect einzubauen, einen Compliance-Flow einzubauen.
Auch Was auch noch nicht reingemacht habe, ist das Thema DSGVO.
Das ist ja auch wichtig.
Zum Beispiel, dass ich von vornherein, wenn jetzt jemand eingeloggt ist und mit seinen persönlichen Daten, der kriegt einen Schlüssel, das ist verschlüsselt und mein Server kann das entschlüsseln.
Und wenn der Mitarbeiter sozusagen verlässt, wird einfach nur der private Schlüssel weggeschmissen und dann kann niemand mehr den Klartextnamen sehen.
Sowas.
Das sind halt kleine, feine Sachen, die sind nicht schwer zum Umsetzen eigentlich, aber die kosten bewusst.
Bewusst wird da in die Tasche gerettet.
Und deswegen habe ich bei Nibu gesagt, das ist von vornherein drin.
Dafür verzichte ich halt eben auf sowas wie eine End-zu-Ende-Verschlüsselung oder was Matrix eben auch kann, ist Federation.
Also ich kann verschiedene Matrix-Server.
Das ist ja eigentlich sozusagen das.
Skalierungsmodelle eigentlich von der Matrix-Protokollsicht her, dass ich einfach verschiedene Matrix-Server bei verschiedenen Menschen hosten kann, ähnlich wie Mastodon, und die sind dann über Federation miteinander verbunden.
Ist aber halt für einen Unternehmenskontext ein Closed-Loop jetzt nicht nötig, sag ich mal so.
Vielleicht irgendwann mal, wenn man sagt, okay, ich will mit anderen Nebo-Servern auch, es hat ja dann Teams und Slack.
irgendwann auch eingeführt, dass ich eine Federation habe, aber es ist jetzt nicht sozusagen das Must-Have eines Unternehmensjets, weil ich will ja eigentlich meine geschlossene Gruppe eigentlich damit irgendwie die Kommunikation sichern, nicht zu anderen.
Das ist ein nettes Goodie, was man dann irgendwann noch hat, aber es ist auf der anderen Seite auch diese, gerade die Federation ist halt nochmal ein ganz großer Brocken in dem Matrix-Protokoll.
Der hätte mir jetzt eben keinen Gewinn gebracht, aber Deswegen habe ich ihn eben das bewusst rausgelassen.
Eben mit Fokus auf mehr Enterprise-Features.
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 eben mit der LLMs oder auch mit BEMAT erzeugt hast, das war ja auch nicht kostenlos.
Wie sieht es denn aus mit Kosten?
Was kannst du denn dazu berichten?
Was ist da deine Erfahrung?
Worauf sollte man da auch achten vor allen Dingen?
Also da ist natürlich bei Kosten, wenn man das mit LMS macht, ist eben der Tokenverbrauch ist durchaus, das ist auf jeden Fall bei generell speckgetriebener Entwicklung ist der Tokenverbrauch wesentlich höher, weil ich halt einfach mehr niedergeschrieben habe im Text.
Es ist aber jetzt nicht so, dass ich da jetzt zwanghaft immer sozusagen endlos ein Ultimate ohne Limit brauche, um irgendwas zu schaffen, sondern es ist ja an sich, bei meinem Fall zum Beispiel jetzt nicht zeitkritisch.
Es gab jetzt ja keinen Zeitdruck.
Und ich habe den halt einfach, das ist sozusagen der kleine Vorteil.
Ich kann ihn einfach machen lassen, parallel mein ganz normales Kundengeschäft, Umsatz erwirtschaften, ganz normal und schaue ab und zu mal rein, wie weiter ist.
Und ob es passt, dann teste ich ab und zu mal, gibt ihm eine Kurskorrektur und dann fährt er wieder von alleine.
Und das ist eben sozusagen der, klar, dieser Token-Invest, das ist mehr zu beziffern.
Ich sage mal so, wenn man jetzt so eine schon höheres Limit-Kontingent-Lizenz ist, ist man bei so 100 bis 200 Dollar im Monat.
Damit kann man schon sehr viel erreichen, weil man hat ja eben dieses Limit und Nur ein volles Limit ist ein gutes Limit.
Also man würde ja dann auch verschenken und die Limits kann ich ja auch einfach ausfüllen.
Das schadet ja nicht.
Das eher, was man sich dann denken muss, wenn man das gegenrechnet, ist, ich habe jetzt hier vielleicht eineinhalb Monate gearbeitet und wenn ich jetzt das traditionell stuffen würde, jede dieser Agents, die ich da habe, müsste ich eigentlich als Person, bräuchte ich als Person erfasst.
Also ich bräuchte, um Den Evo-Server, das klassische Software-Projekt, bräuchte ich drei bis vier Leute, die das leisten.
Und drei bis vier Leute, eineinhalb Monate, kostet ja, jeder weiß selber seine Herstellungskosten, wie viel da flöten geht.
Und die können dann nicht parallel noch ein normales Kundengeschäft machen.
Und das Endergebnis am Ende ist ja, dass ich mich dann unabhängiger mache, also strategischer Gewinn, Und ich spare mir dann die Lizenzkosten für eben das Produkt, was ich dadurch ersetze.
Und Chat ist ja jetzt, sag ich mal, es ist jetzt schon wirklich der Worst Case.
Ich fange fast Greenfield.
Matrix-Protokoll gibt es schon, aber fange fast Greenfield an.
Aber wenn man jetzt sagt, okay, ich habe jetzt hier ein Open-Source-Projekt, das gibt es schon.
Ich hätte jetzt auch nichts gehabt, wenn ich jetzt einen passenden Matrix-Server gebe, 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 halt hier einfach mal ein bisschen das B-Mart testen und das speckgetriebene Entwicklung, weil man muss da klar sagen, das ist auch bewusst nur was für richtig schwere Probleme.
Also so klein ist, ich habe es auch mal versucht für ein bisschen Infrastruktur, Cloud-Formation machen und so, das ist zu viel.
Das ist einfach eisgeil zu viel.
Da verbringt man so viel Zeit mit.
Erstmal erklären, Speck aufbauen und mit Vibe-Coding geht das schneller.
Klar.
Also so kleine Sachen, aber wenn ich jetzt ein richtig großes Problem habe, dann ist es mit B-MAT schon, es ist eigentlich schon auf Produktentwicklungsniveau, was man dann haben muss.
Und das bringt mich aber zu einem Punkt.
Bei aller Euphorie, ich finde das sehr 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.
Du kennst das Bus-Problem oder Truck-Problem.
Du hast das jetzt im Alleingang gemacht.
Sagen wir mal, du bist morgen nicht mehr da, aus welchen Gründen auch immer.
Wie geht es denn da 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 Nutzern müssen das.
Also wie geht man denn mit so was dann professionell um an der Stelle?
Hast du da auch direkt ein paar Empfehlungen?
Da kommt wieder die Spezifikation zu tragen.
Und zwar, was mir von von einer Seite wichtig war, ich wollte nicht verstecken, dass ich es agentisch entwickelt habe.
Es gab mal von Cloudflare einen weibgecodeten Matrix-Server, der dann gerade die entscheidenden Dinge nur gar nicht implementiert hatte, nur die API, also das Interface hatte.
Und sowas ist natürlich schwer.
Aber wenn ich es mit diesem speckgetriebenen Ansatz, ich habe jede Story, alles ist dort drin.
Auch meine, die eigenen Agents, die ich gebaut habe, alles drin.
Also jeder, der sich ein Cloud Agent hat, kann sich das auschecken und weiterbauen, weitermachen.
Und es steht da alles drin.
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.
Es steht ja alles da, es ist nichts versteckt, nichts 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 das transparent ist, was das angeht.
Dass man auch wirklich sagt, okay, hier sind alle Storys.
Und das ist halt, es zwingt eigentlich das B-Mod ein dazu oder die speckgetriebene Entwicklung, weil ich eben nicht so viel auf den Kontext vertraue.
Weil sozusagen das Kontextwissen ist ja nicht feste ist ja nur lokales, temporäres Wissen.
Und wenn ich natürlich eben nur im Kontext arbeite, ist halt natürlich vielleicht manche Entscheidungen oder so, sind halt dann weg.
Und so sind die alle sauber als ADR dokumentiert.
Ich habe eine Akt 42 Doku, mir aus meinen Storys, aus meiner Architektur raus generieren lassen.
So ist alles, alles, alles ist da.
Auch wenn ich nicht würde.
Der seligste Wunsch, den man manchmal hat, dass solche Dinge da sind und jetzt sind sie da, weil die Fleißarbeit, die da manchmal mit verbunden ist, natürlich von den Ergebnissen.
zum Teil auch erledigt wird.
Aber nichtsdestotrotz, wenn man mal ein bisschen in die Zukunft springen würde, wenn du, sagen wir mal, der Zukunftsfilme irgendwann zurückschaut oder vielleicht auch heute schon, nachdem du ein paar Wochen in der Zeit schon investiert hast, gibt es doch sicherlich trotzdem ein paar Dinge rückblicken, die du vielleicht anders entschieden hättest.
Gibt es da was, wo du sagst, wenn ich das Projekt jetzt nochmal neu aussetzen würde, das würde ich anders machen?
Klar, was ich anders machen würde, das glaube ich, ist auch ein traditionelles Software-Break.
Ich würde viel stärker von vornherein.
Test getrieben und Behavior getrieben entwickeln.
Und da ist sogar eine lustige Anekdote aus dem Ganzen.
Und zwar, ich habe ja eben das Matrix-Protokoll, da gibt es ja schon Clients dafür.
Und eben für dieses Event-Mechanismus, da habe ich lange gebraucht, bis ich dann eigentlich draufgekommen habe, hey, ich nehme mir den Element, gibt es auch einen Web-Client, Und der Element-Web-Client hat auch eigene Playwright-Tests.
Und wieso adaptiere ich nicht einfach die Playwright-Tests von diesem Element-Client für meinen, um die Matrix-Arbeit zu testen, Matrix-Spec zu testen?
Und so was, und eben gerade, dass ich einen Agent habe, der sich mit diesem Matrix-Protokoll, mit dem eigentlichen Problem, sage ich mal so, auskennt, das würde ich, wenn ich jetzt ein neues Projekt mit Specgetrieben mache, würde ich 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-Schreib-Prozess, in den Entwicklungsprozess, auch im Review, gerade dieses Review, das ist echt, weil wenn der was erstellt, auch Codes oder Storys, das ist meistens so ein One-Shot.
Das kann man sich vorstellen wie ein mini-Vibe-gecodetes Artefakt.
Und er braucht einfach diesen Review-Prozess.
Da findet er immer irgendwas.
Immer.
Deswegen ist zum Beispiel auch diese Partyrunde, die ist auch so wertvoll, weil die finden immer irgendwas.
Irgendeine Lücke, wo man denkt, okay, es liest sich 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 halt die Möglichkeit hat, gleichzeitig auf ganz viele Köpfe mit ganz viel unterschiedlichem Wissen zu zugreifen.
Und das auf Knopfdruck.
Und das muss man, glaube ich, das ist...
was man sich jetzt mit dem ganz auch agendischen Engineering, was man sich, es ist eine andere Art von Arbeitsmuster, was man hat.
Ja.
Und wenn man ehrlich ist, das hatte man ja früher auch schon in traditionellen Softwareprojekten, wo man angefangen hat und dann hat man eigentlich eher auch so jetzt halt selber halt einfach runtergescriptet damals und dann hat man festgestellt, oh 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.
Das sind halt trainierte Freitans-Buster.
Genau, mit diesen Freitans-Buster wurde ja die DSLM getrainiert.
Ja, genau.
Das ist ja nicht trainiert worden mit den besten Software-Projekten, sondern, ihr kennt es ja, 95% der Software-Projekte sind ja die schlechtesten gewesen.
Und ich glaube, dass bei gerade NLMs, sie können schon, man geht manchmal vielleicht davon aus, dass sie programmieren können, aber sie sind eher wie eine Art, sozusagen jemand von der Straße, den man sieht, der könnte vielleicht auch programmieren, sozusagen.
Er kann auch irgendwas runter tippen, aber erst eben diese Skills und so weiter, das macht dann aus einem sozusagen Generalisten einen Spezialisten.
Und da muss man, glaube ich, als Firma, also wenn man da anfangen will, generell auch für jetzt nicht sowas wie Nebu, muss man dort langfristig dort die Architekturarbeit reinstecken in diese Skills, in dieses Setup.
Und dann habe ich aber auch die Möglichkeit, dort, wie ich jetzt zum Beispiel mit meinem Matrix-Agent oder mit meinem Sicherheits-Agent, gleich von vornherein irgendwelche Compliance-Rules und so weiter gleich mit umzusetzen, direkt mit reinzugeben.
Um dann nicht hinterher festzustellen, jetzt habe ich zwar was produziert, aber ISO irgendwas kompatibel ist es jetzt nicht.
Sondern ich kann mir dann einen ISO-Agent bauen, der das gleich von vornherein mitmacht.
Und das war so ein bisschen so eine Erkenntnis, auch gerade in den letzten Wochen, wo ich ihm viel Bugfixen gemacht habe, wo es mir dann irgendwie nervt hat.
Ja, wieso macht er das jetzt nicht?
Jetzt hat er wieder das Event vergessen.
Weil er halt dann, er fängt ja immer mit einem neuen Kontext an und so.
Und klar.
hat er vielleicht ein bisschen irgendeinen Stand mal beim Training vom Matrix-Protokoll reingekriegt.
Aber sich dann einfach mal fünf Minuten hinzusetzen, zu sagen, okay, jetzt, es gibt dir ein Skill zum Skill bauen.
Hier hast du den Matrix-Spec, mach mir ein Skill draus.
Das sind ein paar Token, die ich da investiere, aber dann später habe ich halt ein viel besseres Ergebnis.
Ich merke schon, ich glaube, es macht total Sinn, dass wir mal eine separate Folge alleine zu diesem Thema aufnehmen.
Ich habe es vorhin schon mal gesagt, mit total Begeisterung heraus und ich glaube, das macht an der Stelle absolut Sinn, dass wir da vielleicht nochmal 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?
Die nächsten Meilensteine?
die ich habe.
Es gibt also noch ein bisschen ein paar Features aus dem Matrix selber raus.
Zum Beispiel es gibt auch die Möglichkeit Spaces zu schaffen.
Also das ist eine Spezialform von Räumen aus dem Matrix, wo ich eben auch Spaces habe.
Ich habe sozusagen die Matrix Features ein bisschen in MVP Phase 2 und Phase 3 eingeteilt.
Momentan bin ich in Phase 2.
Im MVP Umfang hatte ich halt sowas Großes.
Grund Setup von dem ganzen Projekt, eine Art Bootstrap-Phase, wo ich meinen Denebo-Server mit einem OpenID-Connect-Server verbinden kann, wo dann alles eingerichtet ist.
Also es gibt einmal die Matrix-Abi 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 OpenID-Connect-Server.
Und zum Beispiel Claim-Mapen und so weiter.
Und das war alles in eins und zugrund Matrix-AP-Features.
Also, dass ich mich einloggen kann, dass ich eine Nachricht schicken kann.
Und dann in der Phase 2 kam dann mir dann noch hinzu, dass ich eben die Admin-UI ausgebaut habe.
So etwas wie Raummanagement, User-Management.
Das hatte ich im MVP nicht.
um überhaupt mal was 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, immer aufgetreten.
Und was jetzt für die nächste Interaktion kommt, ist das Thema Medienhandhandling.
Also dass man eben auch Bilder hochladen kann und so weiter.
Das ist eine eigene Sektion im Matrix.
Und dass man das zum Beispiel auch mit irgendeinem Objektstore verbinden kann.
Und dann, was bei Matrix auch noch draufkommt, ist eben dieses Thema mit den Spaces, dass ich eben für verschiedene Projekte zum Beispiel Spaces anlegen kann.
Genau.
Dann ist es weitestgehend fertig, was so die normalen Features angeht.
Und dann habe ich noch so ein paar...
Ideen, was langfristiger ist.
Zum Beispiel, dass sich die Admin-Oberfläche, das, was auf Admin-Seite läuft, dass es eine Art eigenen Raum gibt mit einem Agenten, mit einem virtuellen User, wo dann zum Beispiel jemand mit dem zum Beispiel Bildungen, Barnings und so weiter, wo dann drauf tauchen, wo dann die Admin-Oberfläche selbst als Chat, dass der Libo selber selbst der Chat füttert und über Inhalte zum Beispiel.
Oder Aufgaben oder zum Beispiel für das Compliance-Thema, dass wenn jetzt jemand einen Compliance, dass der Compliance-Officer, wenn er dann auch hätte, auch dann Möglichkeit zu Zugang zum Chat, beantragt einen Compliance und dann kriegt er eine Nachricht über einen Nebo-Chat, die Compliance-Report wurde erstellt, kannst du hier runterladen und sowas.
Also, dass es ein bisschen mehr, noch ein paar mehr managementfreundliche Sachen gibt.
Oder eben, was ein schwieriges Thema ist, das habe ich 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 der Verschlüsselung selbst, es gäbe die Möglichkeit, das zu lösen, auch dass ich Compliance-mäßig ein gutes Weg habe, aber die Matrix-Clients unterstützen das nicht tatsächlich.
Es nennt sich S-Crow-Key, das ist so, dass die Nachrichten dann im Client doppelt verschlüsselt werden, einmal über den normalen Matrix-Schlüssel.
dass die innerhalb der Matrixwelt verschlüsselt sind und dann parallel noch mit einem zusätzlichen zweiten Schlüssel, der dann von einem Hauptschlüssel entschlüsselt werden kann für diese Compliance-Geschichten.
Aber diese Doppeltverschlüsselung können Clients eben nicht.
Und da kommt eben noch ein Punkt für die, wenn jetzt die API soweit steht, und zwar das Thema Client.
Weil ein Ich will natürlich bei einem Chat auch Push-Dachrichten haben, Notifizierungen.
Und die offiziellen Element- oder Matrix-Anwendungen laufen ja unter der Element-ID.
Ich kann zwar den Element Push-Servers benutzen, kann man einfach so benutzen, aber bin ich ja wieder abhängig.
Da habe ich mir eine Abhängigkeit.
Aber ich will ja vielleicht meinen eigenen Client haben.
Und da kommen wir dann zu einer spannenden Sache.
Und zwar, es gibt einen Client, der nennt sich Fluffy-Chat, der ist von der Lizenz her auch.
glaube ich sogar bei G2 Lizenz.
Und da kam mir schon, also während des ganzen Überlegens, steht es auf der Roadmap, dass man diesen Fluffy-Chat-Client nehmen könnte, eine eigene B-Mart-Modul dazu, wo ich den customisen kann.
Auf meine Firma, auf mein eigenes Branding.
Da kann ich dann meine eigenen Farben reinmachen und dann kann ich diese App eben selber in einem App Store deployen.
unter meine eigene Domain oder über, es gibt ja auch Möglichkeit, auch bei Apple mit privaten Apps zu deployen, wenn ich das Zertifikat habe.
Und dann kann ich eben daraus meine eigene Chat-App bauen, immer wieder.
Wenn ich das eben als Speck habe, das habe ich aber vorhin schon mal so ein bisschen mit Open Source bekommen, das war dann so ein Aha-Effekt damals, zu sagen, hey, ich kann ja sozusagen als Teil von Nebu dieses Customisen selber als Speck 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 customizt er mir das alles.
Weil ich kann das ja, also wenn ich das einmal selber für mich mache, kann ich mir auch eine Speck erzeugen, was muss ich ändern.
Und dann kann ich das ja daraus wieder ein Skill bauen, an anderen zur Verfügung stellen.
Das hört sich vielleicht so, 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 einlesen in das Projekt, muss die Architektur verstehen, mich mit dem Contribution irgendwie 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 merchen.
Und das ist regelmäßig.
Und das ist halt sehr aufwendig auf Dauer.
Aber wenn ich das eben in eine Spezifikation, in ein Markdown-File, ein primitives Markdown-File reinpackte, was ich geändert haben will, dann kann ich das ja auch eben einen Agent machen lassen.
Dann mache ich mir halt eben einen Agent, einen Fluffy.
Customizer-Experte, der kennt sich mit dieser Fluffy-Architektur aus, der sucht sich dann schon die richtigen Stellen aus.
Der Reverso Engineering, das kennen die LMs ja, das ist ja Brote-Butter-Geschäft, sag 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 er gar nicht beim Anmelden, gar nicht nach Registrieren und so weiter fragt, 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 Compliance-mäßig gute Ende-zu-Ende-Verschlüsselungen habe.
Und wenn ich das Muster dann auch auf andere Sachen anwende, dann wird es spannend und zwar, Viele von den Zuhörern kennen vielleicht dieses klassische Make-or-Buy-Decision.
Und da hat man 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 Prozent.
Die würde eigentlich gut passen, aber so ein bisschen tickt.
Zum Beispiel Login mit Ossos ist halt nicht drin.
Oder irgendwelche branchenspezifischen Sachen sind halt nicht drin.
Das ist halt so ein kleines Quäntchen fehlt.
Aber es wäre eigentlich gut.
Wo man dann oft in Unternehmen hört, ach, da haben wir leider selber nicht die Kapazität für das umzusetzen.
Und ich höre bei dir schon raus, das würdest du jetzt delegieren, richtig?
Genau.
Und zwar, da kann ich jetzt sagen, okay, da habe ich genau dieses Problem.
Ich muss das ja verstehen, dann nehmen wir 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 darum kümmern.
Da nehme ich doch lieber die Die Lizenz-Variante, die passt vielleicht auch nicht zu 100%, aber ich habe wenigstens jemanden, der kümmert sich drum.
Und das ist halt eben mit dieser Speck oder agentischen Entwicklung, ändert sich das jetzt.
Jetzt kann ich sagen, okay, ich nehme diese Open-Source-Variante, die zu 95% passt oder zu 90% und baue den Rest als Speck, einfach definiere ich als Speck und lasse die einfach reinlaufen.
Und wenn ein Update vom Master kommt, lass ich es halt einfach wieder reinlaufen.
Wieder und wieder.
Das kostet dann halt vielleicht eben ein paar Token und dann habe ich aber dann ein Produkt, das so passt.
Ich muss nicht eben, wie ich jetzt von Null einmal anfange, aber es gibt ja schon vielleicht auch, lass es 70, 80 Prozent sein, die es schon passt.
Brauche ich halt den Rest einfach dazu.
Und dann wird dieses, und wenn das halt gut ist, vielleicht kann ich ja dann auch einen Politiker in den Mainway, manchmal zum Beispiel, vielleicht OpenID 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 OpenID Connect, macht es ja auch keinen Fehler, das in den Haupt wieder zurückzuspielen.
Aber ich habe selber sozusagen meine eigene Customization habe ich als unabhängiges Skript oder Speck dastehen.
Und da muss ich mich halt nicht mit dieser Architektur und sowas, sondern ich mache das halt stupide immer und immer wieder da rein.
Da habe ich mal eine spannende Frage.
Wenn Wie ist das denn bei Nibo?
Wenn wir jetzt Zuhörerinnen haben, die sagen, das will ich total spannend für mich damit einbringen, habe ich die Möglichkeit?
Hast du es Open Source gemacht?
Ja, ich habe sogar mehrfach geopen sourced.
Selbst einmal in GitHub, das ist ja klassisch, aber GitHub ist halt auch ein zweischneidiges Wert.
Es ist zwar open source alles und bekannt, aber jeder weiß ja, eigentlich gehört es ja Microsoft.
Hier im deutschen Raum hat die Bundesregierung selber OpenCode vor einiger Zeit gelauncht.
Das ist viel von Kommunen genutzt.
Auch die Ministerien und so weiter haben da mittlerweile viel drin.
Da kann man sich einfach, da gibt es ein GitLab.
Da kann man ein GitLab, ein Account 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 diesen Softwareverzeichnis auf.
Ich leider noch nicht.
Ich habe da noch ein bisschen strukturelle Fehler drin gehabt.
Aber wenn das jetzt mein Feature-Branche gemerged ist, dann sollte das da auch auftauchen.
Und dann sehe ich, habe ich da halt einen Überblick über die ganze Software da ist.
Ich habe vor einigen Zeit schon mal drauf geschaut.
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 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 Nebu Kadneza.
Und das ist sozusagen das Schiff, das einen die Unabhängigkeit fährt.
Ich habe auch viel, 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 Nebo, weil es macht ja nur Sinn, wenn ich das Souveränität gesamtheitlich betrachte.
Und aktuell ist es sogar so, dass ich eher in OpenCode reinpusche und dann halt, wenn ich dort fertig bin, dann mache ich halt einen Sync auf GitHub, weil es halt bekannter ist, aber die Hauptentwicklung habe ich jetzt auf OpenCode.
Dort gibt es eben, coolerweise gibt es auch eine NC-Pipeline, kann man einfach GitLab-C benutzen.
Ist zwar ein bisschen restriktiver, als wenn man die anderen Runnern nehmen, als wenn man das jetzt auf Cams hat, aber man könnte ja auch einen eigenen Runner da einfach registrieren.
Ich habe mir das auch mal eben notiert, weißt du was?
Ergreifen einfach mal die Gelegenheit.
Ich würde sagen, das hört sich eigentlich schon nach 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 nochmal 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örerin.
Wer Lust hat, sich einzubringen bei dem Projekt, wir werden es verlinken in den Show Notes.
Darfst gerne contributen, richtig?
Genau.
Und wichtig ist, Nutzen und Feedback geben.
Und eben davon lebt es ja am Ende.
Und man darf es auch gerne Battle testen.
Also richtig.
Das ist eben aufgrund, deswegen diese Architektur aus Go und Elixir 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 so Lasttests drin.
Das kommt dann jetzt in der Phase 3, wenn ich das mal richtig deployen und richtig mal unter Stress.
Lokal ist es ja immer ein bisschen witzlos, aber sollte er 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 Hint für OpenCode, weil da ja auch Kommunen schauen.
Vielleicht ist ja direkt auch die 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.
In der Kleine gibt es auch ein Projekt, aber nicht jede Gemeinde kann halt ein Kubernetes-Cluster betreiben, aber vielleicht irgendwo ein Docker.
Das einzige Voraussetzung ist, ist ein Docker-Host.
Dann kann ich einfach Docker-Compost ab und dann läuft es.
Auschecken, bauen, starten.
Mehr ist es nicht.
Wunderbar.
Das klingt sehr, sehr gut.
Ich denke, wir sind am Ende unserer Folge angelangt.
Und das finde ich auch schön, dass du gegen Ende auch nochmal aufgelöst hast, weil dann ein Niveau kommt an der Stelle.
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 Niveau selber an der Stelle oder auch OpenCode.
Und ich fülle mich auch schon mal an, wir werden natürlich auch zum nächsten Delay, 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.
Es soll ein bisschen Spannungsbogen aufgebaut werden.
Aber wir werden natürlich zeitnah da auch wieder drauf hinweisen und natürlich am ersten Sonntag des Monats das Ganze vorab schon als Blogartikel veröffentlichen.
Philipp, es hat mir sehr, sehr viel Freude gemacht.
Insbesondere, weil wir natürlich noch zwei Dinge haben, die wir aufgreifen werden.
Eine ist das Back-Driven Development.
Das, glaube ich, kann auch noch eine ganz, ganz spannende Folge ergeben und das Thema Open Code.
Und von daher freue ich mich, wenn wir uns schon bald wieder hören.
Ich hoffe auch, dass es den Zuhörerinnen genauso gefallen hat und greife nochmal ein.
Philipp hat ganz klar eingeladen, Nibu doch zu unterstützen und mal reinzuschauen.
Macht das bitte und wir freuen uns aufs nächste Mal.