# Agentic AI in FinTech: Compliance as a Strategic Advantage

**Podcast:** HMZE
**Published:** 2026-05-23

## Transcript

Alle lernen im Moment.
Das ist ein einziges gemeinsames Lernen.
Und wir sind alle zusammen auf dieser Reise.
Das ist, glaube ich, das Einzige, was man im Moment mit Gewissheit sagen kann.
Herzlich willkommen zu einer weiteren Folge unserer neuen Staffel von HMZE Beyond Bike Coding.
Der Podcast, in dem wir den fundamentalen Change in der Softwareentwicklung begleiten.
Ich bin Sebastian Heidemeier zu Erben, CTO bei North.io.
Und ich bin André Neubauer, CTPO bei Trusted Jobs.
Schön, dass ihr wieder da seid.
Heute zu Gast Florian Thiel, seines Zeichens Engineering Director bei Abwest, einem Startup, einem FinTech Startup, so rum.
Und auf Florian sind wir aufmerksam geworden, weil er bei LinkedIn einen spannenden Artikel, Building with AI at Abwest, veröffentlicht hat.
Und da haben wir gesagt, den laden wir uns ein und fragen ein bisschen aus.
Genau.
Und Florian erzählt, warum die strenge Regulierung, die ja so ein Fintech normalerweise, der so ein Fintech unterliegt, sich für Abwes sogar als Vorteil erweist.
Jetzt gerade im AI-Zeitalter und wie pragmatisch die Firma das Thema Agentic Engineering angeht.
Eine super spannende Folge.
Ja, zieht sie euch rein.
Freut euch drauf.
Viel Spaß beim Hören.
Herzlich willkommen Florian Thiel zu unserem Podcast-Format.
Ich freue mich, dass du da oder wir freuen uns, dass du da bist und ein bisschen was über Abwest erzählst.
Du hast ja mal so einen sehr spannenden LinkedIn-Post vor, glaube ich, ein paar Wochen gemacht, der durchaus unser Interesse geweckt hat.
Und da haben wir uns gedacht, hey, laden wir dich doch mal ein.
Heute klappt es mit der Aufnahme.
Und genau, ich würde dich wie immer bitten, dich einmal kurz vorzustellen.
Ich freue mich sehr, dass ich hier sein kann.
Vielen Dank für die Einladung.
Ich bin Florian Thiel.
Director of Engineering bei UpWest.
Für die, die UpWest nicht kennen, wir sind noch kein Haushaltsname.
Wir sind ein Investmentinfrastruktur, API Scale-Up, das mittlerweile durchaus populäre Kunden wie N26 und Revolut hat und zukünftig die DKB, unser erster sehr großer Kunde von klassischen Banken, diesen Kunden quasi den Handel mit Aktien, ETFs, Geldmarktfonds und allen anderen Instrumentenklassen erlaubt und wir bilden das in einer API Fullstack ab.
Wir sind eine Produkt- und Technologiefirma, primär sind jetzt ungefähr auf 300 Leute gewachsen.
Als ich in die Firma gekommen bin, waren wir 50 Leute, haben also auch ein enormes Wachstum mitgekriegt und wir sind so ungefähr die Hälfte Product Engineering und natürlich haben wir Account Managers, Sales, Banking, Risikoabteilungen, was man halt so hat, wenn man ein Tech-Unternehmen mit einer Banklizenz ist.
Interessehalber Vollbanklizenz?
Nein, wir haben vor allem die Lizenzen, die wir für den Handel brauchen.
Also wir haben eine Handvoll Lizenzen, aber nicht alle.
Och Sinn, unnötige Komplexität und Ballast.
Da spricht Adria aus Erfahrung.
Lizenzen zu bekommen ist nicht einfach und Lizenzen zu halten auch nicht.
Sobald man die Lizenz hat, ist man unter Compliance-Regeln, regelmäßige Audits.
Das hat auch laufende Kosten, Lizenz zu halten und andersrum nicht braucht, wenn man nicht haben.
Wir sind in den letzten vier Jahren eben massiv gewachsen, haben angefangen mit den Neobanken und Fintechs.
weil die mitgehalten haben mit der Integrationsgeschwindigkeit, die wir gebraucht haben, um das Produkt zu beweisen und auf den Markt zu kommen.
Und wir haben uns dabei die Reife gebaut, in die traditionellen Banken reinzukommen und genug Vertrauen und Stabilität und die Robustheit, die man braucht, um mit traditionellen Banken zusammenzuarbeiten.
Ich bin seit ungefähr 20 Jahren in...
irgendwie in Technologie in Berlin unterwegs, von Beratungsunternehmen zu Enterprises und kleine Startups in Rollen zwischen Infrastruktur, Teamleitung, Architektur und eben jetzt auch quasi Department Leadership.
Und ja, weil Abyss ist mein erstes Fintech-Unternehmen, also vorher unterschiedliche Bereiche abgedeckt, aber nie in Finance.
Also ist es für mich auch eine Lernreise, was vor allem die Domainkomplexität angeht.
Also alles andere, was ich vorher gesehen habe, ist sehr viel einfacher gewesen als Finance und vor allem Investment.
Das ist durchaus eine Freude und man lernt jeden Tag was dazu.
Aber man ist auch immer wieder überrascht, mit welcher Komplexität.
das eigentlich unter der Haube zugeht, was man nicht so sieht, das Kunde.
Ja, und aktuell baue ich, ich baue jetzt bei RAPES seit vier Jahren das Unternehmen mit auf und habe jetzt aktuell ein Tribe, was sehr Client-facing ist.
Wir sind ein API-First-Produkt.
Eins meiner Teams verwaltet die ganzen Client-Konnektivitäts-Fragen.
Natürlich eine REST-API, wir haben asynchrone Event-Interfaces, ein Team kümmert sich darum, wir haben interne Operations, ein, zwei Teams kümmert sich darum und wir haben ein relativ neues Produkt gelauncht, was auch Operations-Interfaces für unsere Kunden nach extern bereitstellt.
Das ist unser einziges Produkt bisher, was nicht direkt...
ein API-Produkt ist, sondern ein Hobbyweihalt.
Bevor wir immer so ein bisschen in diese Kernthemen einsteigen und da hat ja Sebastian schon gespoilert, dreht sich bestimmt ein bisschen auch um den LinkedIn-Artikel, den du geschrieben hast.
Wie arbeitest du denn?
Also was ist denn so quasi aktuell dein Tech-Stack?
Machst du dir wieder die Hände dreckig, wie man so schön sagt?
Ja, natürlich.
Also das ist eine der größten Änderungen, glaube ich, im In den letzten neun Monaten, muss ich sagen, seitdem, ich glaube, es ist seit November, wo das so richtig wieder losging, dass es Freude gemacht hat, Adjentec AI zu benutzen.
Wir haben das in der Company schon sehr lange.
Wir haben seit Jahren GitHub und Copilot im Einsatz.
Das war aber lange Zeit mehr so bessere Autovervollständigung.
Und das war so für mich häufig kein...
keine ausreichende Hilfe, um wieder anzufangen, Code anzufassen, weil der Fall für mich einfach zu groß war.
Und das hat sich in den letzten sechs Monaten komplett gedreht.
Wir haben vor kurzem, da kommen wir gleich noch ausführlicher dazu, Claude für die ganze Kömmer ausgerollt.
Und das ist wirklich so der Durchbruch gewesen.
Wir haben vorher schon Gemini gehabt.
Wir leben ziemlich viel in in Google Enterprise, in Google Workspaces und da ist Gemini ganz gut integriert.
Die haben ja auch ein CLI-Tool, was nicht ganz mit Cloud Code mithalten kann heutzutage, aber war lange Zeit auch ziemlich gut.
Das hat mich dann wieder dem Code nähergebracht und das für mich möglich gemacht, um Teams zu unterstützen.
Ja, und wirklich wieder mal die die Hände schmutzig zu machen.
Also heutzutage ist es Cloud Code, Cloud Chat, ein bisschen Gemini.
Wir haben ein bisschen eine fragmentierte Umgebung.
Das hat damit zu tun, dass wir natürlich als reguliertes Unternehmen und vor allem, weil wir sehr viel mit Kundendaten zu tun haben, ein paar Compliance-Anforderungen haben, die nicht ganz trivial zu erfüllen sind.
Wir haben mit Gemini Zero Data Retention und Data Center nur in Europa.
Es ist einfach zu lösen.
Mit Cloud ist es im Moment nicht möglich.
Das heißt, wir haben so ein bisschen ein fragmentiertes Feld, wo alles, was interne Dokumente berührt, ist mehr in der Gemini-Welt.
Alles, was Code ist, ist Cloud-Code.
Also es ist definitiv, wenn ich mit meinen Engineers spreche, das mächtigere Tool, aber eben im Moment noch nicht für alle in allen Anwendungsfällen möglich.
Eine Frage in dem Zusammenhang.
Wir hatten letzte Woche, oder in der letzten Folge, Dan Shapiro, die Sex-Level für Gentic Software Engineering.
Wo würdest du euch da einordnen?
Also wo geht es da für euch hin?
Also kennst du den Artikel?
Ja, wahrscheinlich.
Ich habe den Artikel tatsächlich nicht im Kopf, die die Kategorisierung dazu haben.
Aber ist ja auch egal.
Wie weit wollt ihr da gehen perspektivisch?
Seid ihr da Richtung Spectrum Development unterwegs?
Oder ich weiß gar nicht, auch im regulierten Umfeld, ich könnte mir vorstellen, dass das auch durchaus nochmal schwerer ist, da wirklich auch eine AI quasi wirklich autonome Software schreiben zu lassen.
Was ist eurer Approach?
Wir haben den großen Vorteil, wir sind relativ Code-First und Approval-Driven Development losgelegt und dadurch haben wir so Vorteile, wie dass alle unsere Pull-Requests haben einen Human Review, das ist auch technisch entforced und auditierbar.
Das heißt, eigentlich ist der Unterschied zwischen der Agent hat den Code geschrieben und der Mensch hat den Code geschrieben aus aus Compliance-Sicht nicht vorhanden.
Im Endeffekt ist es immer ein Mensch, der dafür gerade steht, für diese Änderung.
Und das macht es für uns natürlich sehr viel einfacher, als wenn man Greenfield anfängt und von Anfang an AI hat und die Build Best in der Code-Basis rum vorbeigehen.
Insofern ist das für uns einfacher.
Ich persönlich für die Sachen, die ich mache, im Kleinen, das ist mittlerweile fundamental Spec-driven, also Open Spec, weil das für mich passt.
Das wird mittlerweile ziemlich am Anfang jedes Projekt gezogen und dann ist die Interaktion, wir schreiben zusammen Spec, wir diskutieren da zehn Minuten drüber und die Implementierung ist dann größtenteils autonom.
Also man guckt da noch mal hin und wieder mal rein, aber häufig sind es auch Tools, die am Ende sowieso eher, Code generieren, der wieder durch Approval-Prozesse läuft.
Insofern ist das Risiko auch relativ gering.
Steckt ja schon wirklich unfassbar viel drin.
Und da würde ich auch gerne, also jetzt sind wir ja fast schon in the meat, aber würde ich auch gerne noch viel stärker reingehen in die Einzelthemen.
Nochmal ganz kurz zum Thema Compliance.
Also das finde ich total spannend, dass ihr sagt, Gemini, da kann eigentlich alles rein, weil, also quasi im regulatorischen Framework seid ihr da safe.
Irgendwie Daten nur in Europa, Zero Data Retention.
Das heißt also quasi alles, was reingeht, wird auch sofort wieder vergessen und damit ist alles cool.
Bei Claude wiederum, genau, weiß man ja, geht es nicht.
Also Code kann da aber auch beliebig rein.
Das heißt also, ich meine, das ist jetzt glaube ich eine Diskussion aus der Vergangenheit, aber früher hat man ja gesagt, ja, Code ist Geheimnis irgendwie und soll man nicht irgendwie mit US-Servern teilen, war ich gar kein Thema gewesen wahrscheinlich, weil ihr von Anfang an quasi das Thema auch anders verstanden habt.
Also ich meine, so Code an sich ist auch nicht...
hat nicht so einen großen Wert, gerade auch, wenn er irgendwie fragmentweise in irgendwelchen LLMs oder auf irgendwelchen Servern landet.
Und daher nachvollziehbar.
Das heißt, ihr müsst eigentlich primär darauf achten, dass da, oder wie macht ihr das sonst so mit Themen, die, sagen wir mal, im Code sein könnten oder codenah sein könnten?
Also ich frage vor allem so, ich meine, Secrets sind natürlich da nicht drin, aber muss man ja aufpassen, dass da keine Secrets irgendwie...
im LLM landen, Zugriffe auf Server-Log-Files für bestimmte Analysen von Problemen oder sowas.
Wie geht ihr damit um?
Genau, also die grundsätzlich, weil wir in der Cloud groß geworden sind, es gibt keine direkten Zugriffe auf Log-Files für irgendwas.
Wir leben in der Google Cloud.
Die Zugriffe, vor allem auf die Live-Systeme, sind sehr kontrolliert und beschränkt.
Wir benutzen Datadog für den ganzen Observability-Stack.
Und da gibt es natürlich einen MCP.
Der ist aber im Moment so konfiguriert, dass so persönliche, personenbezogene Daten da nicht zugreifbar sind.
Das ist, das ist was, wo wir gerade dran arbeiten, wie wir das besser hinkriegen, weil das teilweise schon eine Einschränkung ist.
Wir haben natürlich so Break-Last-Procedures, wo man für einen Incident-Fall Zugriff auf Server, auf Daten kriegt.
Das ist dann aber kontrolliert und protokolliert.
Aber für den allgemeinen Fall ist das per MCP verfügbar und für die Agenten zugänglich.
Alles klar.
Aber wenn wir da jetzt gerade schon sind, oft die Gefahr, dass wir auch quasi heute zwischen den Themenblöcken springen.
Eine Sache, die ich mir mitgenommen habe, ist halt, dass ihr euren eigenen MCP-Gateway geschrieben habt.
Kannst du dazu mal ein bisschen sagen, was so die Motivation war, das zu tun?
Ich kann es mir fast denken, aber so mal ein bisschen die Story drumherum.
Ja klar, also es ist, der ist nicht von null selbst entwickelt.
Das ist am Ende ein Cloudflare Produkt.
Cloudflare hat MCB Gateway als Produkt.
Wir haben ein paar Sachen drangeschraubt, die für uns passen.
Was wir eben brauchen, ist Impersonation für alle MCPs.
Wir haben sehr viele Systeme, die eigentlich SaaS-Systeme sind.
Also Datadoc ist eins dafür.
Wir benutzen Linear für Work-Tracking.
Die haben alle MCPs und wir müssen natürlich sicherstellen, dass die Zubriffe immer im Namen der Personen passieren, die den Agenten bedienen.
Und insofern hängt das alles bei uns in den SSO-Systemen drin und die expiren auch regelmäßig.
Also man kommt nicht umhin einmal am Tag.
einmal den SSO-Tanz zu machen, aber dann sind die Agenten und auch die MCPs von allen Systemen, die wir benutzen, wieder verfügbar und kommen eben mit den Zugriffsbeschränkungen, die man persönlich hat.
Also wenn ich aufgrund meiner Rolle Zugriff auf personenbezogene Daten habe, dann kann ich die auch sehen.
Also das führt uns jetzt weiter in das Mietthema, aber wir bauen gerade Zum Beispiel auch in Data genau an sowas, wo wir Data-Tagging durchziehen, also alle Datenströme, die wir haben, an der Quelle mit Attributen zu versehen, wo ich feststellen kann, wie sensibel sind diese Daten und darüber können wir dann auch Zugriffskontrolle machen.
Und das hat natürlich wieder Wert für die Agenten, weil ich dann in BigQuery...
bestimmte Datensätze einfach sehen kann und einer Rolle oder eben nicht.
Und genau diese Probleme, die man sonst hat, dass wenn man Agenten relativ weitgehende Zugriffsrechte gibt, dass man sich ganz schnell in einen Bereich bewegt, der in der regulierten Umgebung nicht angebracht ist, das umgeht man damit.
Also wenn von vornherein Datenklassifikation da ist, wir benutzen Google Workspace für alles, was so Dokumentenaustausch angeht.
Auch da gibt es Dokumentenklassifikationen von geheim über nur für den Firmengebrauch bis zu extern und man kriegt eben dann auch die Kontrollen geschenkt dazu, dass man nicht aus Versehen mal ein Dokument einem Kunden freigibt oder dass eben die Agenten das benutzen, um damit Umsatz zu machen.
Das ist eigentlich super clever, weil du damit im Endeffekt ein existierendes Layout einfach nachnutzt und halt auch, also nicht nur rückwirkend, sondern auch nach vorne raus.
Du brauchst ja keinen zusätzlichen Prozess auszudenken.
Das ist ein ganz großer Vorteil, den wir, glaube ich, aufgrund der Zeit, in der wir angefangen haben, den Tools, die wir zur Verfügung hatten und der fundamentalen Architektur, die wir gewählt haben, wo wir diese ganzen Vorteile haben.
die uns das Leben vor allem mit den Agenten sehr, sehr leicht machen.
Ja, super spannend.
Das ist erstmal ein bisschen counterintuitive.
Man würde denken, Financial Services super reguliert.
Das heißt, extrem schwer, KI einzusetzen.
Aber im Gegenteil, dadurch, dass ihr halt Tech-First gestartet seid und halt entsprechend automatisiert habt und die Compliance mehr oder weniger automatisiert abgebildet habt, seid ihr da absolut top aufgestellt.
Super, super spannend.
Das ist natürlich auch dann für, wenn man an agentische Softwareentwicklung und den Agenten ein bisschen mehr Freiheit zu geben denkt, wenn es immer ein Approval-Gate gibt am Ende, ist das was, was man sehr viel lockerer handhaben kann.
Natürlich ist das Problem, wie viele Leute haben, ist Validierung, Testen.
kann ich automatisches Feedback für Agenten bereitstellen.
Das ist auch am Ende ein großes Thema für uns.
Wir haben eine eventgetriebene Microservice-Architektur, wo eben so Ende-zu-Ende-Test, vor allem in so einer komplexen Domäne, wo man nicht viel Signal dafür kriegt, wenn in einem Service eigentlich alles funktioniert, weil am Ende ist es ein Ende-zu-Ende-Flow über zehn Schritte und auch zwischen unterschiedlichen Banken, Handelsplätzen und so weiter, der funktionieren muss.
Und das ist eine ganz große Herausforderung, wie wir das hinkriegen, dass wir Agenten wirklich Freiheiten geben können und Agenten Feedback zur Verfügung stellen, sodass die auch längere Zeiten autonom arbeiten können.
Wir sind jetzt schon voll im Meet drin, würde ich sagen, aber ist auch überhaupt gar kein Problem, weil es ist ja total spannend.
Und auch da habe ich jetzt schon wieder Drei Folgefragen.
Ja, wenn wir gerade bei dem Thema sind.
Also Event-Driven-Microsoft-Architektur mit auch Banken oder sagen wir mal unterschiedlichen externen, sagen wir mal, Services angeschlossen, die ihr ja quasi von denen ihr Daten bekommt oder zu denen ihr Daten schickt.
Und darüber müssen ja tatsächlich verteilte Transaktionen auch abgebildet werden können.
Also es muss ja wahrscheinlich auch möglich sein, quasi die einzelne, also aus verschiedenen Service Calls die zusammengesetzte Transaktion dann komplett wieder zurückzurollen, wenn irgendwo in der Kette was schief läuft.
Das heißt also, ihr müsst auch mit externen Systemen beziehungsweise also auch externe Systeme irgendwie mit einbeziehen in die Tests.
Erstmal verstehe ich das richtig oder bin ich da irgendwie auf dem falschen Dampfer?
Und die Folgefrage wäre dann, Wie macht ihr das?
Also mockt ihr dann auch die externen Systeme?
Also geht es ein bisschen in die Richtung StrongDM.
Die haben ja sogar sich externe Systeme dann komplett nachgebaut, um tatsächlich noch besser automatisiert testen zu können.
Also die, ja, der Event Layer ist bei uns komplett intern im Moment.
Also es geht nur um Services, die wir bei uns haben.
Die externen Schnittstellen sind sehr, sehr unterschiedlich und häufig industrie-spezifisch.
Also mit den Handelsplätzen gibt es ein spezifisches Protocol, was man mit denen sprechen muss.
Natürlich, wir haben mit Banken und Verwahrstellen zu tun.
Ganz viel davon ist klassisch CSV-Dateien und SFTP.
Auch das gibt es noch, so End-of-Day-Prozesse, wo man dann sogenannte Reconciliation macht.
Also eigentlich, man überprüft, dass unsere Sicht auf die Welt, wer welches Geld hat, welche Transaktionen wo stattgefunden haben, übereinstimmt mit dem, was die Welt um uns hat.
Auch sie.
Und insofern ist es nur intern eventgetrieben.
Ganz viel dieser Prozesse, die schief gehen, sind nicht transaktional, sondern die werden dann über Compensating Actions abgebildet.
Also im Zweifel eine Rückbuchung.
Wenn man irgendwo viel gebucht hat, dann macht man halt eine Buchung die rückwärts.
Wir haben ein zentrales System, was quasi die doppelte Buchführung verrundet.
uns macht, das konsumiert alle Events, die Geld bewegen im ganzen A-Best-Universum und darüber können wir das nachverfolgen und damit ist das einfach eine kompensatorische Mokung, die wir dann machen, wenn was schiefgelaufen ist.
Und die zweite Frage, die du gestellt hast zu Mocks, ja, wir haben ein paar naive Mocks für unsere Fremdsysteme, vor allem in den Testumgebungen.
Es gibt ein paar Firmen, die uns deren Testumgebungen bereitstellen.
Also da gibt es auch so Sandbox-Systeme, die man benutzen kann.
Für ein paar Sachen, wo es das nicht gibt, haben wir uns das selbst gebaut.
Das ist aber noch nicht, also das ist bei weitem nicht perfekt.
Wir haben so ein paar Sachen, wo wir Instrumente haben, also eine Aktie oder oder einen ETF, der sich immer in einer bestimmten Weise verhält, zum Beispiel, wo die Mocks dann so sind, wenn du bedachst und was kaufst, dann geht das immer schief.
Oder wenn man mit dem Kunden was macht, dann hat der immer zu wenig Geld.
So Sachen können wir natürlich machen.
Beeindruckend.
Beeindruckend.
Eine Sache, ist es okay, Sebastian, wenn wir ein bisschen von diesem Thema weggehen?
Total.
Genau.
Ich bin auch dankbar, dass du jetzt was fragst, nicht, dass ich hier irgendwie die ganze Zeit...
Was mich so ein bisschen in dem Zusammenhang gefragt hat, was ja schon ein relativ komplexes Setup ist, unser Lieblingswort, glaube ich, Sebastian und meins Harness.
Jetzt hat man ja auch im LinkedIn-Artikel gelesen, dass ihr relativ frei, also genau, doch den Leuten relativ freie Hand lasst, was so das Tooling und so halt angeht.
Wie kriegt ihr dann eine Klammer darum, wenn so die Infrastruktur drumherum ja doch wahrscheinlich ein bisschen spezifisch oder ein paar Besonderheiten halt hat.
Also die Firma ist eigentlich mit minimaler Technologie gegründet worden.
Also wir laufen auf dem Google Stack, wir haben Postgres-Datenbanken, wir haben Golang, wir haben Kafka-Events.
Fertig.
Es gibt keine anderen Sprachen, es gibt keine großen anderen Frameworks.
Damit kriegt man natürlich ein bisschen ein bisschen Gemeinsamkeit und alles, was nach außen passiert, ist eben von irgendeinem Adapter-Service gekapselt.
So Anti-Corruption-Layer-mäßig auch, dass wir von einer Event-Welt in eine Dateiaustausch- oder transaktionale Welt gehen können.
Damit kriegen wir so ein paar Grundlagen abgebildet, weil die Surface-Area einfach nicht so groß ist.
Also ganz viele Dinge.
funktionieren ähnlich oder gleich.
Und jetzt die Einführung von Cloud, seitdem wir den Rahmenvertrag haben, führt das natürlich auch dazu, dass obwohl die Leute die angemessenen Tools verwenden können, ziemlich viele Leute sich auf Cloud gestürzt haben, weil es eben vor allem in der Softwareentwicklung im Moment eins der, wenn nicht das, leistungsfähigste Tool ist.
Und man eben in der Firma, wenn alle Leute das benutzen, einen sehr einfachen Austausch hat.
Also ich glaube, alles andere ist im Moment zumindest in der Softwareentwicklung, in der Fernsehgruppe.
Und macht ihr da irgendeinem, du hattest vorhin schon gesagt, ihr macht, habe ich jetzt OpenSpec, nicht SpecKit?
OpenSpec habe ich gehört.
Ja, OpenSpec ist, das ist so ein bisschen für meine Projekte die Präferenz.
Da kommen wir zum AI-Toolkit, auch aus dem Artikel.
Das AI-Toolkit hat so ein bisschen die Firmengrundlage.
Das ist homegrown, aber eigentlich ein Planungs- und Softwareentwicklungsprozess, der in dem AI-Toolkit lebt.
Ich muss ein bisschen grundsätzlich das AI-Toolkit erklären.
Es ist eigentlich ein Lied-Report mit Skills, Rules und Workflows.
Und ein paar ambitionierte Leute in der Firma haben damit angefangen und haben sehr viel allgemeines Softwarewissen destilliert.
Also als wir in dem Moment, wo wir auf einmal sehr viele Tokens zur Verfügung hatten, hat das dazu geführt, dass es einfach wurde zu sagen, okay, wir brauchen ein bisschen so generelle Softwarewissen, was für uns sinnvoll ist.
Das destillieren wir jetzt.
runter in Skills und Rules und Agents und die leben jetzt in diesem AI-Toolkit.
Das hat so ein paar abwärts spezifische Skills, es hat aber auch Regeln, wie dass wir immer signierte Commits haben.
Also Dinge, die nicht selbstverständlich sind, aber firmenspezifisch.
Entschuldigung.
Dass wir da eine gemeinsame Basis haben, die ist aber bottom-up gewachsen.
Das ist relativ opinionated in einigen Bereichen und der Teil, der am herausforderndsten ist, ist so den spezifischen Firmenkontext da reinzukriegen.
Also so, was sind eigentlich unsere grundlegenden Architekturpatterns?
Was ist wichtig für das Business?
Also diesen ganzen Kontext, der hilft, vor allem in der richtigen Dosis, den Allianzenentscheidungen zu treffen.
Viel ist allgemein technologisch und Software-Entwicklungsgrundlagen im Moment drin.
Und das ist ein System, das kann man sich einfach in seinen Agenten laden.
Also wir haben sogenannte Profile, wo man eben eine vorgefertigte Sammlung von Skills, Agenten und Regeln hat, die dann für, sagen wir mal, Data Engineering oder für Go Engineering vorgefertigt sind.
Das kann man durch einfach in seine Cloud Session laden und dann hat man diesen Kontext.
Man kann den auch customizen und sein persönliches Profil haben.
Aber wir haben eben so eine Sammlung von bestimmt 50 Skills.
20 Agenten.
Ja, ich glaube, das ist tatsächlich, würde mich es andersrum eher verwundern, wenn, also zumindest ab einer gewissen Größe, wenn Firmen halt gar nicht, also es gar nicht selbst beeinflussen, weil, wie du gerade gesagt hast, was sind die Guidelines, ob es jetzt fachlich, nicht fachlich sind, also die ganzen Rahmenbedingungen, die musst du ja irgendwie in deine Skills, Workflows, Agenten, was auch immer halt irgendwie reinkriegen.
rein Interesse, weil wir uns mit dem gleichen Thema auch beschäftigen, basiert das auf irgendwas?
Oder ist das from scratch?
Also habt ihr, weshalb nicht, GSD geforkt und dann gesagt, so jetzt quasi machbar weiter?
Oder habt ihr das?
Nee, das ist wirklich from scratch.
Also es ist nicht besonders komplex.
Die Grundlegenden, der Grundlagenlayer ist ja relativ dünn.
Der ist so ein bisschen, wie kriegt man das verteilt?
Wie kriegt man das in in Cloud und in OpenCode reingeruckt und fertig.
Genau, ja, da machst du wahrscheinlich, weiß nicht, Git-Submodules zu oder so.
Ich hatte mich eigentlich eher gefragt, wie sieht euer Workflow dann jetzt zum Beispiel aus?
Wie viele Schritte habt ihr?
Wie feingranular sind halt irgendwie die Agenten oder die Skills, die Workflows, die daraus entstehen?
Genau, aber...
Ich entnehme dem, es ist schlank gebaut.
Es ist relativ schlank.
Wir sind als Company sehr aus dieser Teamautonomie-Ecke gekommen.
Das heißt, es gibt gemeinsame Architektur, die Kontrakts nach außen.
Was die Teams machen, da gibt es gewisse Freiheiten.
diese Richtung funktioniert auch das AI-Toolkit.
Also man nimmt eben das, was man braucht.
Es gibt keinen gemeinsamen, detaillierten Entwicklungsprozess.
Es gibt natürlich auf der oberen Ebene gibt es natürlich unseren Software-Development-Lifecycle, wo Dinge wie es gibt ein Vier-Augen-Prinzip, was technisch durchgesetzt wird für Pull-Requests.
Es gibt bestimmte Test-Stages, durch die man Services schieben muss, wie Deployment funktioniert.
Das ist auf der Ebene automatisiert.
Wir leben in GitHub und GitHub Actions, wo das Ganze größtenteils technisch enforced wird.
Also zum Beispiel die Voraussetzung, dass es einen unabhängigen Reviewer geben muss, der eine Approval für einen Challenge macht.
Das wird einfach technologisch durchgesetzt.
Damit ist auf der lokalen Ebene ein bisschen mehr Freiheit für die Teams möglich.
Macht Sinn.
Dann vielleicht nochmal eine Abschlussfrage dazu.
Sprich, das ist im Prinzip auch im GitHub ein Repo, wo einfach entsprechende Skills drin liegen, Agenten, Regeln, die ich mir komplett ziehe sozusagen und dann einfach lokal noch meinen meinen Harness mit quasi oder in meinen Harness reinwiren muss, weil irgendwie für Cloud muss es halt in der Cloud MD dann drinstehen für OpenCode wahrscheinlich in der Agents MD oder so und dann bin ich up and running sozusagen.
Genau, also es ist ein Repo, das checkt man aus.
Das hat ein bisschen Supportinfrastruktur dazu.
Ich kann halt sagen, wenn ich das so global installiert habe, dann wired das sich in die systemweite.
Cloud-Konfiguration rein, dann ist das einfach überall verfügbar.
Oder ich kann sagen, ich möchte das projektspezifisch, sodass man das Pro-Repo hat, aber prinzipiell kann das beides.
Es gibt ein bisschen so ein Installer-Tooling drumherum, dass ich eben diesen Schritt mit dem Inst-Cloud-Wire nicht selber haben muss.
Macht Sinn.
Ja, mit Agenten.
Also von früher hat man als Team irgendwie Code geschrieben, jetzt hat man aber ein Team von Leuten, die eigentlich Agenten haben, die Code schreiben.
Also wie funktioniert da die Kollaboration im Workflow?
Wir sprechen über eine Feature, wie auch immer, eine Story in Epic, was auch immer.
Dann entscheiden wir uns, was wir bauen wollen.
Wie wird dann gebaut?
Baut einer dann alles?
Genau, wenn du das kurz erklären könntest.
Also in ganz vielen Fällen sind die Features, die wir specken, klein genug, dass das eine Person bauen kann und man dann den Review-Prozess im Team verteilt.
Also wir haben natürlich auch in dem Review-Prozess einen Agenten, da haben wir sogar noch Copilot und Claude, die wir jetzt dann teamspezifisch so ein paar Präferenzen haben.
der Teams, die tatsächlich auch Frontend machen in einer Firma, die sonst nur Backend und API macht.
Insofern sind die Anforderungen natürlich ein bisschen unterschiedlich.
Aber prinzipiell ist mit diesem erweiterten Schwierigkeitsgrad, nämlich mit drei, vier Leuten gemeinsam über eine Spec zu iterieren und dann über den Code, der aus dieser Spec entsteht, zu iterieren, den Schwierigkeitsgrad haben wir uns noch nicht gegeben.
Und das ist auch eine der Herausforderungen, die ich sehe, wie eigentlich Softwareentwicklung in Teams funktioniert.
Vor allem in der relativ komplexen Domäne.
Also bei uns ist die Technologie, man muss verteilte Systeme beherrschen, aber die eigentliche Komplexität ist nicht unbedingt eine Technologie.
Das ist eigentlich alles industrialisiertes Wissen.
Aber wie man diese Systeme baut, ist relativ viel Expertentum.
Und das haben auch noch nicht so viele Leute gemacht.
Und es gibt den goldenen Pfad dafür noch nicht.
Also viel davon ist auch explorativ.
Man muss sich ganz gut in der Domäne auskennen, um dann zu gucken, wie baut man das dann eigentlich in Software.
Vor allem, wenn man mit minimalen Produkten, über die man iteriert anfängt, in Finance.
Das muss natürlich alles so sein, dass das minimale Produkt absolut feature-reduziert sein kann.
muss aber natürlich von Compliance und Sicherheit, Robustheit keine Abstriche machen darf.
Und das ist für so, wie Teams funktionieren und wie Adjuncted Development Teams beeinflusst, ist bei uns, glaube ich, noch ein bisschen eine Spezialsituation, eben weil es nicht einfach nur Software Engineering ist.
Wir stellen unsere Leute als Product Engineers ein und wir verlangen auch der Interviewprozess.
fängt schon damit an, dass es ein Produktinterview gibt.
Wir gucken, sind die Leute willens und in der Lage, über den Tellerrand zu gucken, von dem, was ihr System macht, welches Problem das eigentlich löst.
Wie denken die über Probleme nach?
Das positioniert uns ziemlich gut jetzt in der Agentic-Welt, weil der Teil, der so das Hardcore-Engineering ist, der wird an einigen Stellen weniger wichtig.
Aber die Herausforderung, diese Leute zu finden und Vor allem auch weiterzubilden, dieses Domänenwissen zu verteilen, ist eine große Herausforderung für uns und die uns wahrscheinlich ein bisschen anders betrifft als andere Firmen, wo wirklich am Ende Produkte mit einer Person und einem Agenten gebaut werden können.
Bei uns ist es sehr, sehr wichtig, dass wir das Wissen und das Warum irgendwie vorhalten können, damit das persistiert werden kann.
wir halt auch über lange Frist Maintenance für sowas gewährleisten können.
Und vorhalten, meinst du damit im Team sozusagen?
Im Team oder gerne auch natürlich in einem Agenten.
Die Rezepte dafür sind, glaube ich, noch nicht gefunden.
Wie kriegen wir das hin, dass wir Systeme haben, die selbst dokumentierend sind?
Das ist ja die alte Frage des Software Engineering.
Wie viel Dokumentation, was?
was dokumentieren und vor allem das Warum.
Also ich glaube, wir haben jetzt eine gute Chance, mit Agentic Engineering da näher ranzukommen, weil wir natürlich überall sehen, dass die Dinge, die für Menschen gut waren, schon immer auch für Agenten gut sind und auf einmal ist es einfacher, das zu machen, weil Geld dafür da ist, wenn es für die Agenten gut ist.
Also ist gute Dokumentation, Architekturdiagramme.
Das ist jetzt alles wichtig geworden.
Ich habe ein Team, die haben angefangen, ihre Architektur in Markdown und Diagrammen zu machen und in eine Form gebracht, dass sie die jetzt nur noch agentisch weiterentwickelt.
Also wir reden mit den Agenten über Änderungen, die sie an dem System machen.
Der Agent schreibt die MD-Files um, macht das Architekturdiagramm neu und erzählt dir dann auch, inwiefern deine Code-Basis nicht mehr zu dem Architektur-Diagramm passt.
Und man kann mit dem zusammen dann anfangen, das weiterzuentwickeln.
Das ist noch kein so ganz großes Produkt, aber das ist ziemlich interessant zu sehen, dass das funktioniert, wenn man sagt, wir pflegen das nicht von Hand, sondern wir pflegen das nur über Interaktionen.
Und es ist auch ein...
ein sehr wertvolles Asset für das Team geworden.
Also es ist wirklich was, was alle Leute in dem Team benutzen.
Das ist ein gutes Beispiel dafür, wie so Kontext im Team funktioniert.
Wobei man sagen muss, das ist halt eine relativ technische Domäne.
Das ist keine Core-Finance-Domäne, sondern das ist eine...
Frontend mit DFFs und ein paar Datenbanken.
Ja, ich habe tatsächlich genau gestern mir auch so ein Skill allerdings nur gebaut für ein größeres Projekt, an dem ich arbeite, wo ich jetzt anfange, auch andere Leute mit reinzuholen und da ist mir aufgefallen, oh, das letzte Update der Dokumentation habe ich irgendwie vor zwei Monaten gemacht und da ist mir aufgefallen, oh, da muss ich mal wieder einen Abgleich machen und gleich einen Skill geschrieben, der das, ja, der wiederum referenziert wird in meinem Commit-Skill, sodass, wenn immer ich ein Commit mache, jetzt automatisch ein Abgleich der Realität im Code mit der Dokumentation gemacht wird.
Mal gucken, wie gut das funktioniert.
Ganz spannend, genau, kleine Anekdote.
Nur, ich weiß nicht, ob ihr die Episode von Lenny, nee, sorry, vom Pragmatic Engineer Podcast gehört habt zu Rust.
War jetzt neulich so eine Rust-Mitentwicklerin dabei.
haben bei Rust so ein Feature, das wusste ich noch gar nicht, dass du, wenn du in der Dokumentation, also im Code sozusagen, da gibt es ja auch Kommentare, Dokumentation, wenn du da Beispiele drin hast, dann werden die automatisch in Tests umgesetzt, sodass du immer quasi feststellst, wenn diese Beispiele outdated sind, weil der Code was anderes macht, weil dann der Test hoht.
Das fand ich extrem charmant.
Okay.
Python hatte das, glaube ich, vor...
Python hat dieses Example-Driven-Development mal eingeführt, wo das auch einfach in Kommentaren ist und deine Test-Frameworks sehen die Examples und dann Code.
Ja, super cool.
Also es war auch total spannend.
Jetzt will ich nochmal einmal kurz ein bisschen tiefer in diesen Prozess nochmal einsteigen, einfach nur um da ein paar Unklarheiten, die ich da noch im Kopf habe, rauszunehmen.
Und zwar, was ich jetzt verstanden habe, in aller Regel ist es eben so, dass eine Person an einem Feature arbeitet sozusagen, dann mit dem Agenten dieses Feature sozusagen entwickelt oder der.
Agent entwickelt und die Person steuert den Agenten und dass ihr aber vorher, und da genau, nur nochmal zum Verständnis, vorher ist das Team sozusagen, iteriert das Team an einem Feature in groben Zügen und nachher gibt es dann auch so ein gemeinsames Review, also irgendwo gibt es ja dieses Vier-Augen-Prinzip, aber gibt es dann auch ein Review im Team, also so ein bisschen Ensemble.
oder ein gemeinsames Review?
Wie läuft das ab, so deiner Erfahrung nach?
Um ein bisschen mehr über den Prozess zu sprechen.
Unsere Teams bestehen immer aus einer Reihe von Engineers und Produktmanager.
Und natürlich ist das, was gebaut wird, dann auch im Gespräch zwischen den Engineers und dem Produktmanager.
Da redet man vor allem darüber, was wir bauen und in welcher...
Welcher Ausbaustufe?
Also viele von unseren Features, die wir bauen, die sind nicht in erster Iteration polished.
Die sind erstmal das Minimale, was wir brauchen, damit das für irgendjemanden nützlich ist.
Wir haben zum Beispiel eins meiner Teams gearbeitet für die internen Operations, also so, dass die ganzen Prozesse, die im Back...
unserer API laufen, dass die für Menschen verständlich visualisierbar sind, wo man Probleme lösen kann, Fehlbuchung, Rückbuchung, so Sachen und dafür einen Interface zu bauen.
Häufig sind die ersten Interaktionen davon relativ simplistisch und da man hat halt einen Statch mit Produktmanager und manchmal auch UX-Design, weil wir haben festgestellt schon noch für diese Interfaces ist es relativ wichtig, dass die gute, konsistente Usability haben über so eine breite Masse, aber da kommen wir jetzt auch mehr dahin, Designsysteme dafür zu bauen, sodass die Agenten auch wiederkehrende Patterns gut können.
Da sind wir nicht von Anfang an gewesen in der Code-Basis, aber die Code-Basis entwickelt sich im Moment rapide dahin, dass sie sehr, sehr, sehr patternbehaftet ist, sodass die auch agentisch zugänglich wird.
Und diese Iterationen, die wir für Features machen, die sind dann häufig so zwei, drei, vier Iterationen.
Die werden von der gleichen Person, manchmal auch andere Personen, je nachdem, wer gerade im Urlaub ist, gemacht.
Aber es ist im Regelfall nicht so, dass es Pairing plus einen Agenten gibt.
Aber die Teams haben natürlich dann Die meisten meiner Teams machen zwei wöchentliche Zyklen und am Ende gibt es eben ein, wir gucken mal, was haben wir in zwei Wochen gebaut, zeigen das intern, zeigen das auch unseren Stakeholdern.
Das ist bei den Teams, die interne Stakeholder haben, relativ leicht.
Das ist für die Teams, die APIs bauen in Investmentinfrastruktur, manchmal ein bisschen schwieriger, weil es sehr, sehr schwer ist, da irgendwas von Zeigbares zu.
zu haben.
Das kriegt man ja nur über Kunden hin.
Das klingt also als wäre sozusagen der Outer-Loop, wenn man so möchte, also sprich der Spritzyklus, relativ wie früher, dass nur innen drin die Art und Weise, wie eben die Software entwickelt wird, der Code entsteht, sich geändert hat und wahrscheinlich auch der Throughput, könnte ich mir vorstellen, nach oben gegangen ist.
Ja, da können wir gleich noch zu reden.
Das ist dann DX und was wir darauf gelernt haben.
Wir haben im Moment noch nichts an den Outerloop gedreht, wobei die Teams, also bei uns ist auch das Teams-Setup relativ lose.
Die Vorgabe für die Teams ist, es ist ein iterativer Prozess und ihr habt regelmäßige Introspektiven.
Das ist so ungefähr das Setup.
Jetzt aus Synchronisationsgründen, weil Teams natürlich auch kollaborieren untereinander, haben sich die meisten auf einen zweiwöchentlichen Rhythmus geeinigt.
Vor allem auch, weil es von der Domäne her schwierig ist, so einen kompletten Value Stream in einem Team zu haben.
Das sind einfach sehr, sehr viele Touchpoints, sodass wir doch so ein bisschen Inselteams haben.
Features relativ schnell eskalieren auf zwei, drei, vier Teams, die irgendwie koordiniert werden müssen.
Das ist so ein bisschen Domänen-intrinsisch.
Man kommt sonst ganz schnell dahin, dass man für jedes Instrument, was man handelt und für jede Variation einen eigenen Value-Stream bauen muss, damit man ihn Ende zu Ende ownen kann, was mit ganz vielen anderen Problemen kommt.
Insofern gibt es diese Kollaboration.
führt dazu, dass wir noch einen relativ klassischen, iterativen Outerloop haben.
Und wahrscheinlich kommt ihr davon auch gar nicht so gut weg.
Also das ist wahrscheinlich so ein bisschen der Constraint der Domäne.
Das kann sein.
Die Teams arbeiten unterschiedlich damit.
Also es gibt Teams, die nicht so viele Synchronisationserfordernisse haben.
an so ein bisschen mehr kann man, like, zu arbeiten.
Also wenn Dinge passieren, die jetzt wichtig sind, und das passiert in Scale-Arves auch hin und wieder mal, dann redet man mit einem Kunden und stellt fest, okay, wir müssen für den Launch jetzt irgendwas machen, was wir noch nicht so geplant hatten.
Dann fiedelt man das einfach in den Zyklus rein.
Das geht schon.
Wir machen keine zwei Wochen Timeboxen, wo es am Ende...
am Anfang ein Commitment gibt, wo am Ende dann geguckt wird, wie sieht das Commitment aus?
Und es ist mehr so ein, wir setzen am Anfang so ein Cycle-Goal fest.
Das ist irgendwie das Wichtigste, was wir liefern müssen.
Und das bildet auch nur so 20, 30, 40 Prozent der Kapazität ab.
Das ist so die Ambition, was entscheidend ist jetzt für diesen Zyklus, dass regelmäßig noch viele andere Dinge passieren müssen, weil man zum Beispiel auch Business-as-Usual-Arbeit hat.
Das ist immer klar.
Also steuern wir nicht in einem sehr klassischen Commitment-Getriebenen und wir gucken dann am Ende, warum hat das geklappt oder nicht.
Zyklus da drauf.
Du hattest gerade noch so ein Triggerwort gesagt, also Triggerwort im LinkedIn-Post.
Die X ist für mich immer, wo ich so denke, hm.
Keine Ahnung.
Sehr hyped.
Ich habe es noch nicht so verstanden und noch den Wert dahinter verstanden.
Ist jetzt quasi für mich die Gelegenheit, dann nochmal ein bisschen besser zu verstehen, was das für einen Wert hat.
Kannst du dazu ein bisschen erzählen, was ihr da macht und wofür es nutzt?
Wir haben angefangen vor zwei Jahren, habe ich ein kleines Framework gebaut, um in der Company ein bisschen zu verstehen, wie ist eigentlich unser Investment Balance.
Zeit verbringen die Teams mit neuen Features, mit Iterationen auf bestehende Features, wie viel ist Keeping the Lights on so Maintenance-Arbeit, um einfach für uns als Engineering Leadership ein Maß zu haben, um zu gucken, muss man da gut steuern.
Und turns out, das ist kompliziert.
Wie misst man Zeit überhaupt?
Gibt es ganz viele Fragen zu Vergleichbarkeit zwischen Teams.
Ist sowieso quasi unmöglich, wenn die Teams nicht exakt ähnliche oder gleiche Arbeitsstile haben.
Das hat nicht gut funktioniert.
Wir haben dann ein Survey-Format.
um so ein bisschen zu gucken, was sind eigentlich die wichtigsten Prioritäten, die wir lösen müssen.
Viel kriegt man auch natürlich im Einzelgespräch raus, aber um das ein bisschen zu substituieren, haben wir mit Surveys angefangen zu gucken, wie zufrieden sind die Leute mit lokaler Entwicklung, mit wie viel sie gestört werden, wie viele Meeting-Heavy-Days gibt es, wie gut funktioniert die Plattform, so Sachen.
Und man stellt halt relativ schnell fest.
Das ist relativ viel Wissenschaft und das möchte man nicht unbedingt in-house machen, wenn man jetzt nicht die Experten dafür hat und die Kapazität auch irgendwie besser einsetzen kann.
Und dann kauft man DX.
Das große Versprechen von DX ist, die haben sich dieses Wissen angeeignet, die haben Sensoren dafür gebaut, die mit deinem GitHub, mit deinem Ticket-Tracker, mit deinen Kalendern mit allem, was du so im System hast, auch mit deinem Kubernetes und deinen Agenten, spricht, um über die Sensoren und über Surveys dir zu sagen, wie gut eigentlich deine Entwicklung oder was Action Points für deine Entwicklung sind.
Und dafür benutzigen wir das auch.
Also wir haben DX erst gegen Ende letzten Jahres eingeführt.
Also wir sind noch nicht so lange in der Benutzung da drin.
zwei größere Zyklen mit auch Surveys dazu gemacht und sehen jetzt die ersten Dinge, die größtenteils bestätigen, was man geahnt hat, aber jetzt vor allem das so ein bisschen substanzieher.
Und zum Beispiel auch für AI, die haben im letzten Jahr angefangen, AI-AuraE zu messen.
Also es gibt Sensoren, die einfach gucken, durch die Agenten, wie viel agentisch produzierter Code fließt bei dir ein, wie häufig hast du darüber iteriert, also hast du gesagt, das war jetzt aber nicht gut, rejected und nochmal gemacht.
Dieses Wissen ist alles da.
Das waren auch so ein bisschen die Agenten-Efficiency.
Können die Leute vernünftig, prompt und vernünftig Kontext bereitstellen, wie gut funktioniert das.
Das ist alles da drin und man kriegt ein Maß dafür, wie viel agentisch produzierter Code.
live geht.
Und das korreliert zu Durchsatz und natürlich den DORA4, sodass man am Ende des Tages auch sehen kann, hat das was gebracht, jenseits von mehr Code produziert.
Den heiligen Gral, ob wir jetzt wirklich bessere Outcomes beobachtbar kriegen, den kriegen wir natürlich auch nicht 100% damit gelöst.
sind wir ja vom Thema Throughput auf das Thema DX gekommen, weil natürlich auch DORA und ähnliche Messungen sozusagen damit korreliert sind.
Die Frage, ihr habt ja wahrscheinlich nicht vorher schon Datenpunkte, die ihr jetzt vergleichen könntet.
Also sprich, wenn du sagst, ihr habt das Ende letzten Jahres angefangen damit, vermute mal, ihr habt da vorher dann auch keine DORA-Metriken gehabt.
Kannst du trotzdem ein Bauchgefühl äußern oder gibt es sogar Daten, die was zum Throughput sagen?
Also das ist was, wo wir noch, das haben wir noch nicht gemacht, aber prinzipiell haben wir die Daten für den Throughput, weil wir natürlich vorher auch mit GitHub gearbeitet haben.
Also die grundsätzliche Infrastruktur hat sich nicht groß geändert.
Die PR-Frequenz kann man wahrscheinlich auch retrospektiv für die.
für die letzten Jahre nochmal bewerten.
Mein Bauchgefühl ist aber, und das hört man natürlich auch in Gesprächen mit den Engineers, die Frequenz und die produzierten PRs sind, das ist mehr geworden.
Natürlich haben wir jetzt einfach dadurch, dass wir diesen Human-in-the-Loop-Approval-Prozess haben, gibt es dieses natürliche Water-Lag.
Das ist wenig überraschend.
dass man auch hier und da hört, dass die Leute ein bisschen geschwästert sind davon.
Vor allem, wenn die Qualität von dem, was in diesem Prozess landet, nicht exzellent ist.
Man muss sich dann doch mit Code abgeben, der manchmal eben doch nicht so ist, wie der vorher war, als den noch Menschen geschrieben haben.
Das ist spannend.
Das ist ein Feinding, was ihr gemacht habt.
Dass die Code-Qualität sich verschlechtert hat.
Nee, das hat sehr viel Fluktuation, vor allem auch über die Modelle und die Agenten, die wir benutzt haben.
Es gibt Leute, die in Domänen arbeiten, wo auch Kontext nicht so gut ist, wo das sehr, sehr schwer ist und wo es auch Beschwerden gibt, dass es sehr schwer ist, den Agenten beizubringen, gute Beiträge zu leisten.
Aber insgesamt, also vor allem jetzt.
nochmal in den letzten zwei, drei Monaten.
Seit Opus geht das nochmal massiv nach oben, das Sentiment.
Also auch was, was man in den DX-Surveys sieht.
Insgesamt ist die Zufriedenheit mit dem AI-Tooling als Unterstützung, die ist sehr hoch.
Ist in den 90er-Andenprozenten.
Alles klar.
Spannend.
Das heißt also Baugefühl, Frequenz.
Der BR hat sich erhöht.
Qualität punktuell verschlechtert, aber quasi zieht wieder an und insgesamt relativ hohe Zufriedenheit mit dem Tooling.
Ja, ich muss noch eine Frage zum Tooling stellen.
Wir hatten ja mal Stefan Schmidt, mehrmals schon Stefan Schmidt hier und einmal unter anderem halt auch zu seinem Human.
Und mich lässt dieses Thema mal nicht los.
Habt ihr da, wenn wir so über Tooling sprechen, gebt ihr da irgendwas, also jetzt nicht vor, aber habt ihr ein anderes Setup?
Jetzt haben wir ja vorhin darüber geredet, dass ihr eine MCP-Lösung gebaut habt, die zumindest immer auf die Rechte des Nutzers zurückfällt, der oder die quasi gerade damit interagiert.
Aber macht ihr irgendwie so Containerisierung von Entwicklungsumgebungen oder habt ihr da irgendwas gebaut für die neue Ära?
Das ist, nee, da sind wir noch nicht.
Also ich habe mir Human auch angeguckt, das Inkrement für das, was wir im Moment haben, ist wahrscheinlich nicht besonders groß ohne große Umbaumaßnahmen.
Also die Agenzen in Containern laufen zu lassen, ermöglicht uns wahrscheinlich sehr viel mehr Freiheiten zu geben, aber dafür müssten wir eben den großen Lift schaffen, signifikante Teile unserer Infrastruktur in wieder sehr schnell reproduzierbare, möglicherweise kontainerisierte Umgebungen zu versetzen.
Und da arbeiten wir gerade dran.
Wir haben gerade angefangen, vor allem für Load-Tests solche Umgebungen zu bauen.
Und das wird ein Stepping Stone dafür, dass man Ausschnitte unserer Infrastruktur sehr schnell und wiederverwendbar hochzieht.
Und dann gibt es eben auch die Option, containerisiert Agenten laufen zu lassen und die alle zusammen in einem sehr geschützten Raum zu haben, wo dann auch Parallelisierung auf einmal interessanter wird.
exklusive Testumgebungen nicht billig zu haben sind, ist eben auch irgendwann Workfree-basierte Mehrfachnutzung von Repositories beschränkt, wenn man die Integrationstests am Ende nicht unabhängig voneinander laufen lassen kann.
Das ist dann irgendwann eine Geschwindigkeitsbeschränkung.
Das ist ganz definitiv einer der nächsten großen Punkte.
Sinnvolle Tests Ende zu Ende.
zu finden, wie wir uns da positionieren, wo für uns der Sweet Spot ist zwischen Aufwand und vor allem Geschwindigkeitsgewinn durch AI.
Dann haben wir das auch nochmal mitgenommen.
Ja, in Anbetracht der Zeit würde ich tatsächlich auch sagen, sollten wir langsam wie üblich auf die Zielgerade einbiegen.
Vielen Dank erstmal schon mal bis hierhin.
Das war extrem spannend und ein bisschen auch schön zu sehen, dass so bestimmte Dinge sich dann doch nicht ändern, beziehungsweise auch, was ja auch irgendwie auf der Hand liegt, dass viele Investments, die früher mal getätigt wurden, einfach immer noch sinnvoll sind, was gerade so Branch Protection und Vier-Augen-Prinzip und so weiter angeht.
Genau.
Wir haben noch zwei Segmente zum Abschluss und das erste ist immer The Reality Check.
Da geht es darum, welche What-the-Fuck-Momente unsere Gäste so erleben in ihrer täglichen KI-Realität sozusagen, aber auch, was gerade der heißeste Scheiß ist.
Genau, hast du da was?
Ja, also hier habe ich keine Hot Takes für alles.
Also größere Enttäuschung von AI habe ich schon länger nicht mehr erlebt.
Was mich ein bisschen nervt, ist so...
Agents Brawls, also jeder und sein Hund hat jetzt einen Agent und es gibt keine Gemeinsamkeiten.
Also Linear, unser Ticket Tracker, hat einen Agent, der ist auch ziemlich gut, aber dafür muss man Skills bauen und die sind geliebend dann halt da.
Der Slackbot hat einen Agent, Gemini hat einen Agent, Cloud hat einen Agent und alle.
Also diese Wiederverwendbarkeit und Plattformisierung ist dann noch nicht da und man muss deswegen aufpassen, wie viele Agents man parallel verwendet und vor allem, wie das bei uns gerade der Fall ist, dass man nicht alles mit allem verbinden kann aus Compliance-Gründen.
Wechselt man hin und wieder mal Agents, das regt einen dann schon auf und da hofft man auf Besserung.
Ja, das ist im Moment so mein...
mein Headpiece, wo ich denke, das könnte man eigentlich mal besser machen.
Und ähnliches gilt für für Context Management.
Context Management, was wiederverwendbar ist.
Das kommt auch bei den Predictions nochmal wieder.
Ich glaube, dass ich da was tun würde, weil ich da was tun muss.
Schießt doch gerne gleich los mit der Prediction.
Prediction.
Ja, also ich glaube, die Dinge, die wir jetzt kurzfristig sehen werden, sind einmal Test-Harnesses und viele Produkte, die eben das sicher machen, Agenten lange laufen zu lassen und gute Signale zu erzeugen.
Das wird natürlich nur Grundlageninfrastruktur sein, weil das immer sehr spezifisch ist, was man da wirklich braucht.
Und das andere ist eben Kontextmanagement.
Kontextmanagement über...
Modelle überagentenübergreifend in einigermaßen standardisierten Formaten, sodass man das mitnehmen kann.
Und vor allem viel wird passieren, glaube ich, im Unternehmenswissen an Agenten weiterzugeben, an LLMs.
Also wir haben ein paar Leute, die da gerade mit experimentieren, mit Meeting Notes, Decisions, alles, was so in der Company passiert.
Was ist ein vernünftiges Modell, das?
für die Nachwelt aufzuheben.
Vor allem auch, wenn man sich um Entscheidungen kümmert, die sich hin und wieder mal ändern.
Entscheidungen, die revidiert werden wegen neuen Informationen.
Das sind interessante Herausforderungen, weil die LLM-Schwetter und Ergänzungen gut sind, mit startischen Informationen umzugehen, aber mit dynamischen Informationen, die eine temporale Komponente haben, das wird sehr viel interessanter.
Ich glaube, wir werden da Produkte sehen, möglicherweise auch.
Spezialkontexte, die in Spezialdomänen sind, die man vielleicht als Zusatz-Powerpack für seine Agenten dazu mieten kann und wie man die Agenten an seine Systeme und Geflogenheiten anpasst.
Interessant.
Ja, ich habe da sofort im Kopf, also wenn ich mir jetzt so...
Mein Projekt, Anguck, da versuche ich genau das auch zu gewährleisten.
Das ist im Wesentlichen einfach eine Mischung aus Skills und natürlich dem Workflow, den ich benutze und dem Code, an dem ich baue.
Das funktioniert per se sowohl mit Cloud-Code als auch mit Anti-Gravity als auch mit Codex und dann am liebsten mit meinem Pi-Harness.
Genau.
Und zusätzlich natürlich noch CLIs für bestimmte, sagen wir mal, als Tool einfach eine CLI, die vielleicht auch nochmal Zugriff auf bestimmte Informationen geben kann.
Aber du hast schon recht, das ist noch relativ gefrickelt und längst nicht, es ist halt sehr tech-spezifisch, das ist längst nicht für andere Wissensarbeitsbereiche nutzbar.
Da könnte es schon noch was Besseres geben.
Ja, meine große Herausforderung ist, dass für meine tägliche Managementarbeit nützlich zu machen.
Die hängt sehr an dem System, was eigentlich ein fortlaufendes Journal ist, was mit Personen und Ereignissen getaggt ist und darauf einen Agenten anzusetzen, der mein persönlicher Coach ist.
Das ist mein Seitenprojekt im Moment.
Ich glaube, da ist noch viel zu holen, aber da ist auch noch viel Arbeit zu leisten.
Vor allem den ganzen Tool-Strawl, den man dafür braucht.
Also ich habe eine zentrale Quelle, wo alles, was so passiert ist, drin ist, aber natürlich linkt das raus nach linear in Git-Repos, in Slack-Konversationen und so weiter.
Das passiert dann doch ziemlich viel an so einem normalen Tag.
Ja, genau.
Da hatten wir mit Uli von Mapbox eine Diskussion.
Für den ist das im Prinzip mit Cloud Desktop schon Realität.
Also der hat Im Wesentlichen seine eigenen Notes, ich weiß gar nicht, wahrscheinlich als Markdown irgendwie lokal dann auf dem Rechner zu legen, hat Zugriff, ich glaube noch nicht auf GitHub, aber auf jeden Fall, ich glaube die nutzen Slack, nutzen Notion, nutzen, ja, also auch Gmail, glaube ich, hat alles verlinkt sozusagen und darüber kann er relativ schnell dann auch, jetzt wenn es um die Vorbereitung von einem Feedback-Gespräch geht, kann er sich relativ schnell alle relevanten Interaktionen, Datenquellen ranziehen und daraus dann ein Feedback auch iterieren mit dem Agenten zusammen.
Das klappt relativ gut.
Vielen Dank, Florian.
Es war wirklich spannend.
Ich finde auf bestimmte Art und Weise sehr cool und erhellend und auf andere Art und Weise dann aber auch wieder sehr pragmatisch und total logisch.
Das macht alles total Sinn.
Und ja, also es macht nicht viel Sinn, das irgendwie anders zu machen.
Von daher klingt es sehr cool und ergibt auch nochmal viel Anstoß für weitere.
Gedanken sozusagen.
Vielen Dank.
Sehr gerne.
War mir eine Freude.
Der HMZE Podcast ist ein gemeinsames Projekt von Sebastian Heidemeyer zu erben und André Neubauer.
Infos zum Gast und Themen aus dem Podcast findest du in den Shownotes.
Diskutieren kannst du mit uns bei LinkedIn und für alles andere, zum Beispiel, wen du gerne mal hier hören möchtest, kannst du gerne eine E-Mail an podcast.hmze.tech schicken.
Vielen Dank für deine Zeit.
Wenn es dir gefallen hat, abonniere den Podcast.
Bis zur nächsten Folge.