# Arendicom Commerce Middleware and AI Strategy

**Podcast:** Becoming CTO Secrets
**Published:** 2026-08-04

## Transcript

Hallo und herzlich willkommen zu Becoming CTO Secrets, dem Podcast von CTOs für CTOs und diejenigen, die es noch werden wollen.
Ich bin Philipp Deutscher, externer CTO, CTO-Coach und Gründer der Becoming CTO-Community und heute spreche ich mit Ricardo Czescon.
Er ist der CTO von Arendicom.
Und wir sprechen über die Modernisierung einer 15 Jahre alten Commerce-Mittelwehr.
Wir sprechen über fehlendes technisches Grundlagenwissen und die Frage, was KI in der Softwareentwicklung tatsächlich bringt.
Wir sprechen darüber außerdem auch, wie aus einem breit aufgestellten E-Commerce-Anbieter eine fokussierte Plattform wird und warum eine AI-fähige Architektur weit mehr braucht als nur ein neues Interface.
Da haben wir einiges vor, Riccardo.
Herzlich willkommen.
Sehr gerne.
Und einen schönen Gruß nach Hamburg, Philipp.
Danke dir, ich danke dir.
Ja, du beschreibst dich, zumindest im Vorgespräch, als typisches Kind der 90er, geprägt vom C64.
Ich bin ein bisschen später eingeschrieben, nicht beim C64.
Und von dem Wunsch, Technik wirklich zu verstehen.
Und wie hat denn dieser frühe Zugang zu Technik, zu deinem Verständnis geprägt?
Vielleicht sogar schon von der CTO-Rolle heutzutage in hindsight.
Ja, absolut richtig.
Ich bin wirklich so ein richtiges Kind der 90er.
Und wenn wir mal ehrlich sind und die heutigen bunten Oberflächen weglassen, Computer und Software funktioniert in der Pike auf, im Grundprinzip immer noch wie vor 30 Jahren.
Das hat mich insofern als CTO geprägt, weil es mir auch durch das Verständnis von älteren System, wo man wirklich noch hardwarenah Software entwickelt hat, wissen musste, wie man Speicher adressiert, wie man mit Hardware umgeht und vor allem der Hintergrund von viel begrenzteren Ressourcen, als sie heutzutage sind, hat es mir so ein Stück weit die Angst vor Komplexität auch genommen in der weiteren Karriere als Software-Ingenieur, als CTO.
und es schärft vor allem den Blick aufs Wesentliche.
Sehr gut.
Und du bist ja jetzt auch schon einige Jahre CTO bei Arendicom, ich glaube seit 2021.
Richtig.
Was war denn der größte Perspektivwechsel?
Du warst ja vorher auch technischer Experte bzw.
Tech-Lead und bist dann in die Unternehmensführung ja mit aufgestiegen als CTO.
Ja, ganz, ganz wichtig an der Stelle ist, Technik nicht als Selbstzweck zu verstehen, sondern wirklich hin zum kompromisslosen Business Value.
Das ist eines der entscheidendsten Dinge eigentlich an der Stelle.
Und was bedeutet das für dich so im Tagesgeschäft?
Woran machst du das denn fest?
Hast du ein Beispiel?
Es ist vor allem ganz wichtig, dass...
die technische Notwendigkeit für Nicht-Techies irgendwie übersetzt werden kann.
Also technische Schulden wirklich in die eigentlichen Business-Risiken zu übersetzen, damit es auch für CEOs, irgendwelche Finance-Chefs, vor allem gegenüber den Kunden auch greifbar wird ein Problem.
So geht es viel auch wieder um Brücken bauen, um Übersetzen in beide Richtungen.
Ja, sehr gut.
Ja, du erklärst Arendicom auch als Amazon nur anders, hast du zumindest mir erzählt.
Das ist ein großer Vergleich, kann man gerne machen.
Wie funktioniert denn euer Geschäftsmodell genau?
Ja, es ist im Endeffekt die Kurzfassung davon.
Was wir mit unserer Mittelwehr versuchen abzubilden, ist eigentlich ein ähnlicher Ansatz wie Amazon, nur nicht im Marketplace-Bereich.
sondern wir holen wirklich auch den lokalen Fachhandel an der Stelle mit ab.
Wir bieten großen Marken die Möglichkeit, den Fachhandel in die Online-Welt mitzunehmen und den Fachhandel auch von Online-Verkäufen der Marke zu profitieren, ohne dass in irgendeiner Form der Fachhandel kanalabilisiert wird.
Was bedeutet das konkret?
Das bedeutet konkret, Die Marken, die Großen, haben den entscheidenden Vorteil mit Arendicom, dass wir Merchant of Records sind, sprich wir der rechtliche Verkäufer zum Endkunden.
Sprich, wir kümmern uns ähnlich wie eine Amazon um die Zahlungsabwicklung, kümmern uns aber an der Stelle genauso auch um die ganzen Steuergeschichten.
Sprich, die Marke braucht keine Fiskalvertretungen im Ausland mehr.
Das komplette Rechtsgeschäft eigentlich dahinter inklusive Steuerbehandlung.
Und die Marke profitiert an der Stelle genauso wie der Händler.
Der Händler nimmt Online-Business mit und die Marke kann extreme Lagerkosten auslagern, weil das Lager wirklich vor Ort bei den Händlern ist.
Und man hat keine Ware im Markt, die man einerseits selber als Marke halten muss, andererseits an den Händler ausspielen muss.
Und wer ist denn so der typische Kunde von euch?
Ein typischer Kunde wäre beispielsweise Piqueur im Reitsport.
Ah, Piqueur, okay.
Ich bin im Reitsport nicht bewandert, deswegen mir sagt der Name gar nichts.
Aber alle Reitsportfans dürfen sich hoffentlich nicht auf die Füße getreten fühlen.
Ihr gebt ja das kundenseitige Shopgeschäft.
an eine Partneragentur ab und fokussiert euch dann schon vollständig auf die Mittelwehr.
Das hast du zumindest auch gerade nochmal so gesagt.
Was war denn der Auslöser für diese Entscheidung?
Schuster bleibt bei deinen Leisten, würde ich sagen.
Das war eigentlich der entscheidende Auslöser.
Spaß beiseite.
Es gibt sehr, sehr viele Agenturen auch in Deutschland, die wirklich auf das Thema Shop Egal, ob das Shopify, Shopware oder sonst was ist, wirklich hochspezialisiert sind, muss man an der Stelle sagen.
Und Rendikom kommt über die 15 Jahre so ein bisschen aus dem Bereich.
Zu der Zeit gab es noch keine vernünftige Shop-Software im Markt und deswegen wurde so ein bisschen das Rad damals erfunden.
Und versucht ein Shop-System zu bauen plus eine Middleware, die dieses ganze Fulfillment-Thema eigentlich mit Steuer, Fiskalvertretung, Rechnungsstellung etc.
bildet.
Jetzt gibt es mittlerweile aber Software, die wirklich gut ist im Shop-Bereich.
Und da ist einfach der entscheidende Punkt, ja, wir sind eine Agentur, sind aber eigentlich spezialisiert auf diese ganzen Finance-Themen.
Da mit einem mittler-, mittelgroßen Team das Thema Shop noch in einer hohen Qualität abzubilden, wird immer schwieriger.
Und da kommen natürlich dann Partneragenturen ins Spiel.
Und die Überlegung ist halt, wir bleiben außen zum Kunden hin weiter die Full-Service-E-Commerce-Agentur, aber beziehen Partner dann, die wirklich tiefere Know-How, gerade im Shop-Bereich haben, einfach mit ein.
Zum Beispiel für so einen Partner, was der mitbringen muss, in welchem Bereich er dann Services oder Lösungen anbietet?
Er muss halt stark im Shop-Umfeld sein.
Also wenn wir von einem Shopware-Shop sprechen, sollte es natürlich eine Agentur sein, die spezialisiert auf Shopware ist.
Wenn wir von Shopify reden, sollte die Agentur spezialisiert auf Shopify sein.
gibt es auch Agenturen, die können beides genauso gut.
Was war denn der Ausleser für die Entscheidung?
Die Entscheidung ist einfach die Teamgröße vor allem.
Die Teamgröße und dieses Know-how.
Es ist einfacher, dieses Know-how einzukaufen, als selber vorzuhalten.
Also seid ihr...
Auch verlängerte Werkbank des Kunden.
Also ihr habt dann hinten raus ja ganz viele Werkzeuge, Dienstleister, Agenturen, die ihr mit einkauft und die ihr dem Kunden zur Verfügung stellt.
Er hat den Vorteil, er muss das gar nicht selber machen.
Die Komplexität hintendran managt ihr.
Und ob das jetzt dann eine Anzahl Eigenlösungen sind, die ihr anbietet oder ob ihr mit einem Partner XY anbietet, das kann dem Kunden erstmal egal sein, oder?
Genau, wir orchestrieren im Endeffekt das gesamte Ökosystem.
Und spielen wirklich Middleware in alle Richtungen, sei es ERP, Postsystem, Shopsystem und versuchen halt diesen eigentlichen Business Value, der für die Marke entsteht, abzubilden.
Heißt das dann auch, der typische Kunde ist eigentlich einer, der sagt, ich will die ganze Komplexität eigentlich gar nicht selber haben.
Ich bin bereit dafür.
halt ein Premium zu zahlen gegenüber, wenn ich mich jetzt um alles selber kümmere und dafür suche ich mir jetzt einen Dienstleister und guck mal an, da gibt es Arendicom, die machen das.
Genau, absolut richtig.
Also gerade vor allem dieser Finance-Part, wenn du dich um diese ganzen Steuerthemen selber kümmern musst, da die Buchhaltung mit einbeziehen musst.
Du hast gerade, wenn du ins Ausland verkaufst, unterschiedliche Regularien.
Du hast unterschiedliche Regularien, ob du von Deutschland ins Ausland verkaufst, vor Ort dann vielleicht Händler hast, die innerhalb im Ausland verkaufen, brauchst eigene Steuernummern etc.
Und das ist natürlich ein riesen Rattenschwanz.
Du bist dann reportingpflichtig gegenüber den einzelnen Finanzämtern.
Für Firmen abzubilden, gerade für mittelständische Unternehmen und größere Mittelständler, ist natürlich nicht allzu einfach.
Und mit unserem Modell, da wir der Ansprechpartner an der Stelle sind und die rechtliche Vertretung im Endeffekt übernehmen, hat die Marke eigentlich den Vorteil und der Händler, es gibt am Ende des Monats eine einzige Gutschrift.
Die kommt von uns und Händler und Marke bekommen ihr Geld.
Wie stellst du dann damit im Hintergrund sicher?
Also ich meine, für den Kunden ist das natürlich...
Einfach und convenient, er zahlt dafür einen gewissen Preis, aber hinten raus kann das natürlich auch komplex werden, wenn du ein riesen Netzwerk an verschiedenen Agenturen, anderen Servicedienstleistern usw.
managen musst.
Wie stellst du denn dann sicher, dass du diesen Bauchladen an Themen, die dann hinten raus irgendwo sein können, dass das A, dass da eine Strategie dahinten dran ist, dass das nicht zu viel wird, dass das managbar bleibt.
Das stelle ich mir aus Portfolio-Management-Sicht.
nicht einfach vor.
Ja, wir achten ganz stark darauf, dass wir extrem zuverlässige Partner an dieser Stelle haben, auf die wir uns wirklich zu 100% verlassen können.
Deswegen auch zu deiner Frage nochmal, vorhin mit der Abgabe des Shop-Ökosystems selbst nach außen an eine Agentur.
Bis heute haben wir mehrere Agenturen ausprobiert und das ist genau der Grund, warum wir aktuell dieses Geschäft immer noch selber machen.
weil wir bisher keine Agentur gefunden haben, die Preis-Leistung eigentlich verlässlich genug ist, damit wir es wirklich abgeben.
Okay.
Und ihr seid, also aus meiner Sicht wird Arendicom öffentlich immer noch stark als oder wird bislang stark als Full-Service-E-Commerce-Anbieter wahrgenommen.
Seht ihr dann den neuen Fokus eher als eine operative Bereinigung oder ist das dann doch eher eine Art grundlegender Identitätswechsel hin zu einer zu einer Plattformfirma?
Ja, grundlegender Identitätswechsel würde ich jetzt nicht dazu sagen, weil wir ja schon seit am Beginn der Zeit eigentlich auch schon immer nach außen ein Shop-System hatten.
Davor war es halt ein selber entwickeltes.
Shopware ist mittlerweile auch seit 2020, genau seit dem Corona-Jahr, Partner von uns großer.
Und seitdem haben wir nach außen hin beim Shop hier schon keine eigene Software im Einsatz.
Also von daher sehe ich es nicht als Identitätswechsel.
Ganz im Gegenteil, wir wollen hier auch noch viel mehr Partnerschaften mit anderen guten Shop-Systemen für kleinere Kunden durch Shopify beispielsweise aufbauen, weil ein richtiges Shopware-System muss man sich genauso erstmal leisten können.
Ja, auf dem Weg dahin, haben wir ja im Vorgespräch auch drüber gesprochen, galt es ja auch, einen 15 Jahre alten Monolithen zu modernisieren.
Absolut richtig.
Wie macht man das, ohne Geschäft anzuhalten oder ohne das laufende Geschäft zu kannibalisieren oder dass es darunter leidet?
Ja, hier ist vor allem ganz entscheidend, man braucht eine vernünftige Migrationsstrategie.
Das klingt ja immer so einfach auf dem Papier.
Da braucht man einfach nur eine vernünftige Migrationsstrategie.
Ja, super.
Aber ihr macht das ja entscheidend gut.
Erzähl mal.
Wichtig ist an der Stelle, dass man sich wirklich klare Gedanken macht, wie migriert man, ohne dass man das laufende Geschäft anhält.
Und da gibt es eigentlich erfahrungsgemäß nur eine wirklich vernünftige Lösung, die ich auch durch die Erfahrung über 26 Jahre in der IT mehrfach gemacht habe.
Man muss wirklich klar gucken, dass man die Domänen sauber trennt erstmal in die einzelnen Parts wie Finance, Abrechnung.
Schnittstellen für beispielsweise Bestände, Schnittstellen für Produktdaten etc.
Sobald man hier eine klare Trennung hat, ist es dann ganz entscheidend, dass man den alten Monolith, man kann ja nicht einfach hergehen und irgendwie abschalten.
Gerade beim Monolith schaltet ihn ab, es fällt alles zusammen.
Aber was super funktioniert, ist einfach der Punkt, wenn man einzelne Funktions-Streams im Monolith einfach nicht mehr so in der Form von der Funktionalität direkt im Code weiterlaufen lässt, sondern an neu entwickelte Schnittstellen dann andockt.
Da das neue Konzept auf einer kompletten API-First-Strategie inklusive Microservices und Events basiert, tut man sich hier mit der Migration eigentlich relativ einfach.
Man kann wirklich explizit im Monolith eine bestimmte Stelle nehmen.
Beispielsweise macht man ein ganz einfaches Beispiel, eine Rechnungserstellung in PDF-Form.
Hier wird im alten Code irgendwo eine Klasse, eine Funktion, whatever aufgerufen, die diese PDF erzeugt.
Man muss aber nicht zwangsweise eine Funktion in dieser Sprache aufrufen.
Man kann ja an dieser Stelle genauso einen API-Call absetzen auf die neue API-First-Architektur, die API verarbeitet und liefert als Ergebnis diese PDF beispielsweise zurück.
Ich kann mir vorstellen, dass einer der schwierigsten, also du hast das am Anfang gerade so schön beschrieben, man muss die Domänen halt erstmal verstehen, man muss sie schneiden.
Und natürlich ist das richtig, aber ganz oft ist das ja schon der erste Stolperstein in Unternehmen, dass sie dann feststellen, naja, um das Thema Finance von anderen zu trennen, naja, die Finance-Themen sind halt im Code hier überall verstreut.
Und um die Domänen erstmal schneiden zu können, musst du dann trotzdem erstmal verstehen, welche Implikationen hat jetzt denn diese eine Domäne und welchen Code muss ich denn dafür anfassen?
Ja, das ist absolut richtig.
Das ist natürlich eine Riesenaufgabe im Vorhinein, bevor man so ein Projekt überhaupt beginnt, hier sich zusammenzusetzen und die einzelnen Module wirklich harte Grenzen zu ziehen.
Welcher Bereich, welches Architekturproblem oder welche Kopplung war denn am gefährlichsten?
Also sei es jetzt aus der geschäftlichen Perspektive oder vielleicht sogar auch aus der technischen?
Hast du das noch, kannst du das sagen?
Ja, also aus der geschäftlichen Perspektive ist eigentlich der größte Schmerz bei der alten Architektur, dass wenn du eine Stelle anfasst, da hier in dem Monolith jahrelang eigentlich immer nur hinzugestückelt worden ist.
auf Schnelligkeit Wert gelegt worden ist und nicht auf die Qualität.
Schnelligkeit und Entwicklung meinst du?
Ja, genau.
Wurden halt teilweise Funktionen an Stellen implementiert, wo sie nichts zu suchen haben.
Ganz einfaches Beispiel an der Stelle.
Das ganze OSS-Steuerthema wurde beispielsweise in der Erstellung beim Lieferschein implementiert, weil es der einfachste Weg war, aber halt leider nicht der eleganteste Weg.
Jetzt passiert Folgendes, du langst irgendwas am Lieferschein an, an der Funktionalität vom Lieferschein und hast plötzlich Auswirkungen auf alle Steuerthemen, egal ob bei der Rechnungserstellung, ein Steuerthema ist, danach bei der Übergabe an Buchhaltungsdateien ein Steuerthema ist oder sonst wo ein Steuerthema ist.
Ja, das stelle ich mir auch schwierig vor, also gerade den Weg dahin zu skizzieren und auch umzusetzen.
Ich habe selber auch aus der Vergangenheit diverse Untaten miterleben dürfen, die Entwickler in der Vergangenheit, ich sage es jetzt einfach mal so, verbrochen haben.
Wobei sie nicht die alleinige Verantwortung dafür tragen, weil natürlich man auch sehr, wie bei euch auch, auf die Zeit gepocht hat.
Und dann kommen natürlich aber auch Lösungen ab und zu mal raus.
Da stehen einem die Haare zu Berge.
Hinzu, man hat einfach mal, weil man sich nicht anders zu helfen wusste, in der Kürze der Zeit J-Boss geforkt und hat im Endeffekt Funktionen in J-Boss eingebaut, die dann da über sehr viele Jahre drin hingen, die dann dazu geführt haben, dass man...
nicht mehr von der JBoss-Version weiter migrieren konnte.
Und dann hing man auf einer alten JBoss-Version fest, die halt auch irgendwann aus End-of-Life war, was Security anging.
Und da hinten dran hing aber noch eine ganze Menge alten Java-Versionen, die man dann irgendwie auch nicht hochziehen konnte, weil der JBoss an diesen alten Java-Versionen hing und mit den anderen nicht mehr funktioniert hätte.
Und der Weg daraus wäre halt super anstrengend gewesen.
Also ich verstehe, wie man...
in solche Situationen kommt und wie viele, das ist im Endeffekt die technischen Schulden und die Zinsen sind, die man dann irgendwann zurückzahlen muss.
Wie sah denn am Ende des Tages dann eure Migrationsstrategie aus?
War das, du hast es ja schon erzählt, hin zu Microservices, aber war das so eine schrittweise Ablösung?
Habt ihr Strangler-Pattern sehr viel eingesetzt?
Nach welchen fachlichen Grenzen habt ihr das denn geschnitten und wie seid ihr vorgegangen?
Nee, es ist bis heute, wir sind ja auch noch nicht ganz fertig an dieser Stelle, es ist bis heute wirklich eine Herausforderung, aber die größte Herausforderung war eigentlich das initiale Schneiden.
Einfach weg von diesem klassischen Monolith, von diesem riesen Wulstankot, wirklich mit einer vernünftigen Kapselung wirklich in einzelne Teilbereiche zu kommen.
Das verhindert genau auch solche Probleme, wie du eben beschrieben hast.
Sobald man eine vernünftige Kapselung hat und beispielsweise Stock nur Stock macht, Produkt nur Produkt macht, Abrechnung nur Abrechnung macht und das einzelne Microservices sind, vor allem in dem Tech-Stack, den wir verwenden in Python, hast du ja auch die Möglichkeit, jeden einzelnen Microservice in einer komplett eigenen Version laufen zu lassen.
Und selbst wenn du mal einen Microservice hast, wo du dann auf einer Version festhängst, ein eigener Microservice, der komplett gekapselt ist und null Abhängigkeiten hat oder möglichst gegen null Abhängigkeiten hat, weil die eine oder andere Library hat man immer als Abhängigkeit, hast du einfach da auch Die Schaß zu sagen, okay, ich komme hier nicht weiter, der Code ist so schlecht veraltet, wie auch immer, ich schreibe einfach diesen kompletten einen Microservice neu.
Wie stark habt ihr das denn umgesetzt?
Also gerade so diese Aufteilung von den verschiedenen Microservices, da gibt es ja viele...
Anti-Patterns, in denen man schnell dann irgendwie reinläuft, dass man dann sagt, naja, ich greife dann jetzt mal doch hier und da auf die Datenbank von dem anderen zu und was auch immer.
Und schwuppdiwupp hast du nicht mehr diese Modularität und diese kleinen Services, die für sich selber genommen stehen.
Habt ihr das wirklich, Hand aufs Herz, habt ihr das wirklich so stringent durchziehen können?
Oder fallen dir heutzutage immer noch Sachen vor die Füße, wo du dann sagst, ja, da haben wir wieder Microservice gebaut, der eigentlich seinen Namen nicht wert ist?
Du wärst ja nicht der Erste, mit dem das passiert.
Wir haben das wirklich, wirklich extrem stringent durchgezogen an der Stelle.
Also es gibt wirklich eine Handvoll Basisklassen, die sich um Grundfunktionalitäten wie Autorisierung oder Datenbankzugriffe kümmern.
Diese Klassen haben aber komplett eigene Versionen.
Das heißt, wenn wir als Billigstes Beispiel nehmen, wir haben irgendwo ein Database Abstraction Layer in der Version 1 und Microservice 1 nimmt ihn in der Version 1 und es gibt einen weiteren Microservice, der nimmt ihn bereits in der Version 2, ist erstmal überhaupt keine wirkliche Abhängigkeit da.
Man kann wirklich danach diesen Microservice nehmen.
gezielt testen auf die neue Version und dann einfach hoch migrieren.
Welche Rolle spielen dann so Themen wie Observability, Rollbacks, paralleler Betrieb?
Also als Plattform verarbeitet ihr natürlich auch geschäftskritische Prozesse für große Marken und wenn ihr die unterlaufenden Betrieb dann modernisieren wollt, dann läuft man ja auch Gefahr, Dateninkonsistenz, Verfügbarkeit, Compliance.
alles zu gefährden.
Welche Rolle spielt das dann dabei?
Observability, Rollbacks, Parallelerbetrieb?
Ja, da hilft eigentlich nur wirklich Testen von A bis O.
Gerade im Bereich Abrechnung ist es natürlich ganz gefährlich.
Da muss natürlich jeder Centbetrag stimmen.
Und da ist wirklich die einzige funktionierende Strategie, lass das Zeug parallel laufen, solange es geht, so gut es geht.
Und dann vergleiche wirklich sauber die Daten.
Und da kommt natürlich heutzutage ganz viel KI zum Einsatz, weil wenn wir hier von ein paar hunderttausend PDF-Dateien beispielsweise in der Abrechnung reden, da willst du keinen hinsetzen.
Egal ob einen aus der Technik, einen aus Finance, das will keiner kontrollieren.
Da ist natürlich KI ganz entscheidend.
Du kannst einfach extrem viele Datenmengen aufs Komma genau prüfen lassen.
Welche Kennzahlen sind dann für dich dann wichtig, auch um zu gucken, ob die Modernisierung wirklich gelungen ist?
Ja, also die Kennzahlen an der Stelle, die beste Kennzahl ist immer die Kundenzufriedenheit als Dienstleister.
Das ist wirklich das A und O.
Könnte ich auch sagen Umsatz.
Ja, der Umsatz ist ja relativ an der Stelle.
Der Umsatz kommt ja durch die Marke.
Wenn die Marke natürlich shopseitig nichts tut, verdienen wir auch weniger.
Was ist mit engineering-lastigen KPIs?
Was ist dir da wichtig, um das so anzuschauen?
Also sowas wie Lead-Time, Cycle-Time, I don't know.
Ja, da wird es dann eher spannend für uns.
Was wir definitiv mit der neuen Plattform überhaupt nicht mehr haben, Geschichten wie, wir langen A an und B gekappert.
Das sind so Sachen, die die Effizienz an der Stelle, wenn du irgendwie ein neues Feature implementierst, wo du vielleicht alleine, weil der Code komplex ist, nicht ein Microservice ist, davor Tage gebraucht hast.
haben wir halt wirklich auf Stunden runtergebrochen.
Und das lässt sich ganz, ganz wunderschön eigentlich an der Feature-Roadmap messen, wie lange dauern Features heute im Vergleich zu früher.
Du hast, glaube ich, gesagt im Vorgespräch, dass du fehlendes Basiswissen über so Themen wie TCP, HTTP, Server-Send-Events und so weiter als mit die größten Blocker im Team siehst.
Kannst du eine konkrete Situation schildern, in der genau diese Wissenslücke eine Modernisierung oder eine KI-Integration dann spürbar ausgebremst hat?
Ja, also eines der größten Probleme heutzutage am Nachwuchs sehe ich, ist wirklich das Basiswissen.
Heutzutage kann fast jeder Teenager in irgendeiner Form coden.
Das Problem an der Stelle ist aber das Verständnis dafür.
Weil nur, weil ich Code schreibe, der augenscheinlich erstmal funktioniert, ist es nicht zwangsweise guter Code.
Bestes Beispiel.
Ich würde sogar challengen, ob die heutzutage alle dann noch Code schreiben oder ob sie dann nicht lieber prompten und da kommt halt irgendwo Code raus.
Ja, aber das ändert ja nichts am Grundproblem.
Nee, natürlich nicht.
Egal, ob du einen Menschen hast, der Code erzeugt oder ob es eine KI ist, die Code erzeugt, das Ergebnis muss jemand irgendwie vernünftig beurteilen können.
Und das beste Beispiel kannst du auch mit der einen oder anderen KI ausprobieren.
Je nach Prompt wird ein ähnlich schlechtes Ergebnis wie bei manchen Juni.
dass Junioren rauskommen, dass beispielsweise eine API pauschal bei jedem Fehler einen HTTP 500 liefert.
Das ist natürlich unter Umständen beispielsweise Ressource nicht vorhanden, nicht unbedingt der eleganteste Weg.
Vor allem das ist auch danach für Weiterentwicklungen auch durch die KI extrem entscheidend, weil wenn immer nur ein 500er kommt, kann Weder der Mensch noch die KI beurteilen, was will die API überhaupt an der Stelle von mir.
Würde aber die API eventuell einen vernünftigen Fehlercode bei Ressource existiert nicht wie ein 404 zurückliefern, dann wüsste sowohl der Mensch als auch die KI, was eventuell falsch ist.
Vielleicht wurde auch eine falsche Validierung übergeben.
Vielleicht wurde ein falscher Suchstring an die API übergeben.
Aber was bedeutet das dann für dich und deine Organisation, wenn du sagst, dieses fehlende Basiswissen ist ein Problem?
Dann ist ja das Thema eher, wie kriegst du halt die Talente, die das alles trotzdem schon wissen und können?
Oder vielleicht sind das ja auch gar nicht mal die Junioren, die du dann suchst.
Oder aber auch, wie machst du Upskilling für deine Team?
Oder wie holst du dir da Verstärkung halt ran, wenn du das als grundlegendes Thema ausgemacht hast?
Das ist mittlerweile ein extremes Thema.
Ich finde, es kommen immer weniger Entwickler nach.
Ich sehe das auch in Gesprächen mit anderen CTOs, mit anderen Leads, dass wir mittlerweile ein richtiges Bildungsproblem an der Stelle haben.
Das fängt an bei den Universitäten bis über die Ausbildungsberufe im IT-Bereich.
Es wird einfach viel zu wenig Grundlagenwissen vermittelt und dadurch sind die Leute eigentlich nicht mehr befähigt zu beurteilen, ob der Code gut genug ist und qualitativ genug ist, wirklich in einem komplexeren Business zu bestehen.
Und an der Stelle hilft eigentlich nur, wirklich selber mehr die Leute intern im Unternehmen an die Hand zu nehmen, aber auch.
versuchen, was in der generellen Bildungsgesellschaft zu ändern.
Ich bin jetzt auch seit knapp zehn Jahren sowohl Ausbilder für IT-Berufe als auch Prüfer mit Ehrenabzeichen der IHK.
Und da muss man eigentlich ansetzen und was bewegen, weil wir werden immer weniger Code schreiben.
Das ist die Realität.
Das muss man auch ins Auge sehen.
Aber wir brauchen immer mehr Architekten, die das beurteilen können.
Und wenn wir heute nichts für die Junioren machen, dann werden wir irgendwann mal keine Seniors mehr haben an der Stelle.
Das ist richtig.
Aber welches technische Basiswissen ist denn für Softwareentwickler im Jahr 2026?
trotz allem, also trotz KI und allem, was dazugehört, trotzdem nicht verhandelbar.
Ich würde mich gerade schwer tun, also ich stimme dir 100% überein in dem, was du sagst, aber wo setzt du da die Grenze von, das musst du noch wissen und das nicht mehr?
Also ganz entscheidend finde ich, dass ein Entwickler seinem Umfeld entsprechendes Basiswissen hat.
Wenn ich jetzt einen Webentwickler benötige, erwarte ich nicht, dass er hardwarenahe Grundlagen kann.
Wenn ich aber einen Webentwickler habe, erwarte ich sehr wohl, dass er ein Grundverständnis für einen TCP und HTTP Stack mit sich bringt.
Zumindest weiß, was sind Pakete, wie fließen Pakete, was machen beispielsweise im HTTP-Bereich HTTP-Header.
Da gibt es eine Litanei von Header, die meisten Entweder sie haben das Wort noch nie gehört oder sie wissen überhaupt nicht, welche Macht dahinter steckt.
Jetzt hast du Beispiele genannt, die halte ich auch für richtig.
Das sind aber Einzelfälle.
Du siehst ja selber, die sind abhängig von der Rolle und von der Verantwortung der Rolle.
Würdest du das immer ein bisschen anders schneiden?
Wenn ich das jetzt mal versuche, auf einem konzeptionellen Level zu lösen, weil ich sage, ich möchte...
Ich muss das ja auch im Bereich der Ausbildung oder im Bereich des Studiums an die Themen ran.
Dann kann ich ja nicht immer anschauen und muss sagen, wenn der jetzt mal Junior-Entwickler werden will, dann muss er das können und das andere nicht.
Aber wenn er das werden will, muss er das können und das nicht.
So wirst du ja nicht die Leute durchs Studium bringen, sondern welche High-Level, wenn du es mal auf ein, zwei Abstraktionslevel drüber schaust, hast du da eine...
ein Verständnis entwickelt, was du sagen willst, das muss mit rein und das kann man auch weglassen mittlerweile?
Ja, also was ich ganz, ganz, ganz wichtig fände, was aber aktuell de facto in Deutschland nicht passiert, in anderen Ländern deutlich mehr, dass auch ein bisschen mehr historisches Wissen im IT-Bereich wieder gelehrt wird, weil historisches Wissen erhöht.
eigentlich die eigene Kompetenz, gewisse Grundlagenfehler zu vermeiden.
Dann lass uns mal das Thema Artificial Intelligence, KI mit reinnehmen.
Ihr habt gesagt, ihr habt KI-gestützte Entwicklungen erst dann ganz bewusst eingeführt, als Qualität und Kosten für euch stimmt.
Das ist erstmal, ich glaube, vom Ansatz her sehr gut.
zu gucken, wie viel Token verbrauche ich denn, was kostet mich das denn und dass ich nicht mehr irgendwie jetzt einen Millionengrab irgendwo schaffe und sobald sich Token-Economy ein bisschen ändert, gehe ich den Bach runter.
Und das mit dem Thema Qualität macht mit Sicherheit auch Sinn.
Woran hast du denn dann den Reifegrad erkannt und irgendwann beschlossen, jetzt können wir das Ganze auch für Code-Generierung einsetzen?
Ja, also wir haben immer wieder Quartalsweise eigentlich das Thema KI für uns als Sparings-Partner immer wieder evaluiert im Team.
Der Reifegrad, der hat sich hier relativ einfach feststellen lassen.
Da ging es gar nicht mal so darum, was kosten wirklich Tokens, weil Tokens waren vor zwei Jahren auch nicht wirklich teurer als sie aktuell sind.
Wenn die Anzahl der verbrauchten Tokens nach oben geht, klar macht das bestimmt in der Kostenrechnung was aus, aber das ist eigentlich über die letzten Jahre auch eher nach unten gegangen.
Was ganz entscheidend ist, was kommt am Ende des Tages, wenn ich mir irgendwas generieren lasse, sei es Code, sei es Dokumentation, sei es Sonstiges.
was kommt dabei raus und wie hoch ist die Qualität?
Wie viel muss ich menschlich noch ran an die ganze Stelle und nacharbeiten?
Weil es bringt mir nichts, wenn ich irgendwie 500 Euro an Tokens am Tag einsetze und im Endeffekt in der gleichen Summe nacharbeiten muss.
Da habe ich mir null gespart.
Was habt ihr für Effizienzgewinne bisher erreicht?
Also den höchsten Effizienzgewinn, da würde ich sagen, der liegt weit über Hunderte von Prozent, also eher 400 Prozent, ist einfach das Thema Dokumentation.
Wenn du wirklich anständigen Code-Qualitativen produzierst, egal ob du den Mithilfe von KI erzeugt hast oder alleine produziert hast und der...
gut lesbar für einen Menschen ist, ist er für die KI auch gut lesbar.
Das heißt, die KI erzeugt dir eine 100% zuverlässige Dokumentation dazu und das in einem Bruchteil der Zeit.
Wir wissen selber, gerade Entwickler, das leidigste Thema für jeden Entwickler ist Dokumentation schreiben.
Wenn jetzt ein Entwickler 50 neue Funktionen am Tag produziert, Ist jetzt überzogen, werden die wenigsten.
Mit Unterstützung von KI sind wir da bei einem relativ realistischen Bereich mittlerweile angekommen.
Schreib dazu mal die Doku, das willst du nicht.
Da verschwendest du Tage und die KI schafft das in einer extremen Qualität binnen Minuten.
Ich hätte sogar gesagt, ich finde die Einschätzung, dass das 400% mehr sind.
400% ist ja eigentlich eine Vervierfachung.
Das ist fast schon konservativ, das so zu sehen, wenn die AI das schreibt.
Ja, also ich muss sagen, wir haben festgestellt, man muss es immer noch ein Stück weit nachkontrollieren.
Das heißt, in der Qualitätssicherung der Dokumentation, da geht wieder Zeit drauf.
Verlierst du wieder einen Prozentsatz, ganz klassisch.
Weil wir haben da mehrfach festgestellt, wenn man es nicht nachkontrolliert, du hast immer noch...
einen ganz kleinen Bruchteil, einen Ausreißer.
Das Problem ist, wenn du bei der Dokumentation Ausreißer hast, dann hat das extrem fatale Folgen unter Umständen.
Es hat fatale Folgen für den Kunden, es hat fatale Folgen für den, der es benutzt und produziert dann eigentlich wieder Folgefehler und das willst du nicht.
Ja, es ist interessant, was du sagst, auch unter verschiedenen Gesichtspunkten.
Also erstens, ich teile eigentlich die Einschätzung, dass ein Engineer eigentlich keine Lust hat, Dokumentation zu schreiben.
Also früher schon gar nicht.
Wurde ich anscheinend auch schon in diversen Orten schon darauf hingewiesen, dass es ja durchaus sehr viele Entwickler gibt, die da voll Bock drauf haben.
Ich denke, was ist los mit euch?
Kenne ich keinen.
Also keine Ahnung, das war jetzt der Teil vom Engineering, der mir am wenigsten Spaß gemacht hat.
Aber da darf ich anscheinend nicht von mir auf andere schließen.
Der Punkt ist ja der.
Software-Engineers haben in der Regel relativ wenig Spaß bei der Absicherung.
Und wenn sie denn mal was geschrieben haben in der Dokumentation, dann haben sie es ja in der Regel auch nicht abgesichert.
Also die Tatsache, dass du jetzt viel mehr Dokumentation endlich schreiben kannst und vielleicht auch agentgestützt nochmal absicherst, ob die Dokumentation auch das ist, was du da drin haben willst, ist eine massive Verbesserung.
deiner Dokumentation auf so vielen Ebenen und das ist es mit Sicherheit auch wert, auch die Tokens, die du dafür ausgibst.
Was habt ihr denn für Effizienzgewinne in der Entwicklung?
In der Entwicklung finde ich es relativ entscheidend.
Jetzt gar nicht mal so im eigentlichen Schreiben einer Funktionalität.
Klar, die KI schreibt dir.
Die Klasse, die Funktion in der Klasse, die Methode, was auch immer, in einem Bruchteil der Zeit, wie es ein Mensch könnte.
Aber wo es viel interessanter wird eigentlich an der Stelle, ist danach beim Testing.
Weil wenn wir mal eine Funktion nehmen, wo ein Mensch vielleicht davor zwei, drei Stunden dran saß, macht die KI, sind wir mal ehrlich, unter drei Minuten in der Regel.
Das ist ein entscheidender Gewinn.
Dieses unter drei Minuten funktioniert aber nur, wenn du davor massiv Zeit als Mensch in Requirement Engineering reinsteckst.
Ja, absolut.
Wo es aber dann wieder spannend wird, der Zeitgewinn oder die Effizienz an der Stelle vom Erzeugen des Codes, die wird relativ viel durch das Requirement Engineering wieder aufgefressen.
Da haben wir vielleicht einen Gewinn von 20, 30, vielleicht sogar manchmal je nach Funktionsumfang 40%.
Was aber ganz spannend wird danach beim Testen.
Auch hier fließt ja erstmal Requirement Engineering rein, weil die KI ja auch den Business Case ein Stück weit für den Testfall verstehen muss.
Der Punkt ist aber der, wenn der klassische gute Entwickler insgesamt bei einer Funktionalität auf 15 Tests kommt, findet ihr die KI nachfolgend durch das eigene Testen der KI.
Die schreibt ihr den Testfile, testet den Testfile und findet ihr meistens neue Testfälle.
Und da kommt eigentlich der Effizienzgewinn, weil aus 15 Testfällen vom Software-Ingenieur werden mal schnell eher 50 Testfälle durch die KI.
Wovon auch alle meistens Sinn machen.
Und das ist ein extremer Effizienzgewinn, weil das vermeidet im Nachgang wirklich Businessfehler.
Mit welchen Folgen für deine CI-CD-Pipeline?
Weil ich meine in dem Fall, mal angenommen, wenn du jetzt fast eine Verfünffachung deiner Testcases hast, dann wird sich das irgendwann auch auf die Laufzeit deiner Pipeline niederschlagen, oder?
Klar, jeder Test schlägt sich auf die Laufzeit nieder.
Aber was ist fürs Business wichtiger?
Ein Deploy, der vielleicht durch eine Vielzahl von Testfällen dreieinhalb Minuten länger dauert oder eine Downtime von drei Stunden danach?
Ja, das ist klar, natürlich.
Aber trotzdem, ich weiß nicht, ob ich die Frage immer zugunsten der Testfälle beantworten würde.
Ich würde ja trotzdem annehmen, dass ich vielleicht auch eine abgespeckte Lane habe, die mir nicht alle diese...
50 Testfälle pro Feature durchgeht, sondern nur ein Subset davon, was ich vorher vielleicht auch mit definiere, weil ich vielleicht doch eine Lane haben möchte, also nenne ich es die ICD-Pipeline, die die Geschwindigkeit vor Vollständigkeit bevorzugt, aus vielleicht mir bekannten oder aus akzeptablen Gründen.
Ja, aber da sind wir ja dann schon eigentlich im Bereich Refactoring.
Es macht natürlich Sinn.
Irgendwann mal, wenn es Überhand nimmt, egal ob von der Zeit oder der Anzahl, macht es natürlich Sinn, dass sich nochmal ein bis zwei Software-Ingenieure zusammensetzen.
Kann man das wieder in Testdomänen unterteilen?
Kannst du mir noch sagen, was habt ihr denn aktuell für Kosten für AI im Monat?
Sei es jetzt Tokens oder Subscriptions, was gibst du im Monat aktuell aus?
Wir kommen wirklich aktuell mit 20 bis 50 US-Dollar pro Entwickler wunderbar weg.
Das ist sehr, sehr wenig.
Aber ist das meiste, was ihr macht, immer noch Code Completion oder ist das schon richtig Agentic AI, was ihr angeht?
Wir nehmen schon wirklich Agentic AI.
Wir haben einen sehr niedrigen...
Token oder Credit Verbrauch an der Stelle eigentlich aus einem entscheidenden Grund.
Wir machen immer, bevor irgendwas an die AI geht, vernünftiges Requirement Engineering und versuchen wirklich durch die Verwendung von sauberen MD-Files auch nicht unnötig Content oder Kontext besser gesagt an die AI weiterzugeben.
Und das spart extrem viel Geld am Ende des Tages.
Also sauberen Kontext und nur den Kontext reingeben, den du wirklich brauchst, auf jeden Fall.
Gutes Requirements Engineering, ja auch, weil es ja hintenrum die Iterationen vielleicht spart.
Auf der anderen Seite stelle ich auch fest, dass gutes Spec-Driven Development, was gerade propagiert wird, eher dazu führt, dass Storys größer werden und komplexer werden.
Was natürlich wieder die Wahrscheinlichkeit von zusätzlichen Iterationen, egal ob jetzt der AI Hand im Spiel hat oder nur der Mensch, aber je größer die Storys sind, umso weniger berechenbar wird auch der Outcome.
Und das gilt natürlich auch, wenn du einen Agent draufsetzt.
Das sehe ich aktuell so als Nachteil beim Spec-Driven Development, weil die Tendenz dazu geht, Storys eher wieder größer zu machen, eher wieder den Kontext nochmal aufzuplänen und sagen, ah ja, okay, die Acceptance-Criteria müssen auch noch rein und die auch noch und ja, das macht auch noch Sinn, was die AI vorschlägt und schwuppdiwupp hast du eigentlich mehr Aufwand als vorher.
Also prinzipiell gehe ich mit mit deinem Argument, sehe aber auch, dass es in der Praxis an vielen Stellen gutes Requirements Engineering erstmal.
den Aufwand für die Engineering-Leistung eher in die Höhe treibt?
Ja, man muss da ein bisschen vorsichtig sein.
Also was ich immer wieder sehe, dass viele auch teilweise schlechte Agentic AI benutzen.
Ich bin ein wahnsinniger Fan von Kiro beispielsweise, weil es ist erst mal...
Absolut egal, welches Sprachmodell unten drunter liegt.
Klar, eine vernünftige LLM ist ganz entscheidend am Ende des Tages für die Qualität, aber auch der Stack oben drüber, mit dem du als Entwickler oder Ingenieur eigentlich kommunizierst, der ist ganz entscheidend.
Hat dieser Stack ein Gedächtnis?
Weil ein Gedächtnis...
verhindert Mehrkosten.
Du hast zwar initial vielleicht höhere Kosten, aber wenn du es zulässt, dass sich Agentic AI hier Sachen merken darf und vor allem auch selber Kontext niederschreiben darf in sogenannten Steering-Files, sparst du dir auf die Zeit massiv Geld.
Und was auch ganz wichtig ist, was viele Unternehmen an der Stelle gar nicht machen, Reviews.
Einmal im Monat, vielleicht irgendwann mal einmal im Quartal auf das Prompt Engineering selbst.
Was geben die Entwickler ein?
Wie geben sie es ein?
Was hat sich die AI gemerkt?
Wo hat sie vielleicht Verständnisprobleme gehabt und deswegen mehr Tokens benötigt?
Da kann man überall gegensteuern.
Und ich sehe schon, ihr seid da recht weit in dem, wie ihr das angeht, auch.
den Ansatz, erst Kosten und Qualität kontrollieren zu können, bevor man den Wasserhahn auftritt und den Agents Gummi gibt, dass sie Gas geben können.
Das ist, glaube ich, auch der richtige Ansatz, um das Thema voranzutreiben.
Wir sind nämlich auch fast schon am Ende der heutigen Aufnahme, lieber Ricardo.
Wir haben aber natürlich, natürlich haben wir immer noch die Rapid-Fire-Fragen mit dabei.
Und ich sehe schon, du schaffst schon mit den Hufen, um die beantworten zu dürfen.
Sehe ich das richtig?
Absolut.
Sehr schön.
Modularer Monolith oder Microservices?
Microservice mit absolut sauberer Domänentrennung.
Ah, sehr schön.
Build, Buy oder Partner?
Alle drei zum richtigen Zeitpunkt, zum richtigen Zweck benutzen.
Ich hätte gesagt, du sagst jetzt eher Partner, aber du hast natürlich völlig recht, alle drei sind wichtig.
Tiefe Grundlage oder maximale KI-Native-Kompetenz?
Muss komplett im Einklang stehen.
Ohne Grundlagenfundament wird die KI dir nichts bringen.
Mit Grundlagenfundament ist es ein absoluter Turbo.
Zumal dürfen wir auch nicht vergessen, EU Cyber Resilience Act kommt bald.
Viel Spaß damit, liebe Vibe-Coder.
Wenn ihr das alles, ja, ich meine das ernst, kannst du nicht jede App da irgendwo hinstellen.
Du musst da irgendwo auch sauber aufzeigen können, was du da machst und wie und wieso, weshalb, warum.
Das ist nicht, die Anforderungen werden steigen.
Ja, es flacht vor allem mal diesen Hype ab und dieses mittlerweile entstandene Buzzword.
Im Vibe-Coding ist fast schon ein Schimpfwort geworden.
Absolut.
Welches Protokoll sollte jeder Backend-Entwickler wirklich verstanden haben?
Das, was er für sein tägliches Brot braucht.
In unserem Fall HTTP.
Na klar, wenn du im Web unterwegs bist, geht nichts über...
geht nichts ohne HTTP.
Wird schwierig.
Vervollständige den Satz.
Ein CTO scheitert, wenn...
Wenn er versucht, schlauer zu sein als seine schlauesten Köpfe.
Das ist richtig.
Das habe ich auch schon in der Vergangenheit oft genug gesehen.
Das geht nicht lange gut.
Manchmal geht es länger gut, als man das hofft.
Riccardo, vielen lieben Dank.
Danke auch für deine Insights, wo ihr seid, wie ihr umgebaut habt.
Ich kenne die Tücken von...
Legacy, Monolith-Umbauten hin zu Microservice-Architekturen.
Ich kenne auch die Pain-Points dahin.
Ich finde es auch schön, von dir zu hören, also mich wieder bestätigt zu sehen, dass der Weg dahin steinig ist, aber oft auch unumgänglich.
Von daher, ich habe wieder einiges gelernt heute.
Dir vielen lieben Dank.
Bis dann.
Mach's gut.
Ciao, ciao.