Der Code wird billig. Technisches Urteil wird unbezahlbar - mit Ricardo Cescon

KI kann heute in wenigen Minuten Code erzeugen, für den ein Entwickler früher mehrere Stunden gebraucht hätte. Doch genau darin liegt eine neue Gefahr: Wenn Code immer billiger wird, steigt der Wert der Menschen, die beurteilen können, ob er fachlich korrekt, architektonisch sinnvoll und langfristig beherrschbar ist.

In dieser Folge von Becoming CTO Secrets spricht Philipp Deutscher mit Ricardo Cescon, CTO von arendicom, über die Modernisierung eines 15 Jahre alten E-Commerce-Monolithen, fehlendes technisches Grundlagenwissen und die Frage, welche Fähigkeiten Entwickler und CTOs im Zeitalter von Agentic AI wirklich brauchen.

Ricardo gehört zur Generation, die mit dem C64 und stark begrenzten Ressourcen programmieren gelernt hat. Diese Erfahrung prägt bis heute seinen Blick auf Technologie: Technik ist für ihn kein Selbstzweck. Sie muss einen nachvollziehbaren Business Value liefern. Eine zentrale Aufgabe des CTOs besteht deshalb darin, technische Schulden so zu übersetzen, dass CEOs, Finance-Verantwortliche und Kunden die damit verbundenen Geschäftsrisiken verstehen.

Wie real diese Risiken werden können, zeigt die alte Middleware von arendicom. Über viele Jahre wurden Funktionen dort eingebaut, wo sie kurzfristig am schnellsten umzusetzen waren. So landete Steuerlogik ausgerechnet in der Erstellung von Lieferscheinen. Eine vermeintlich kleine Änderung konnte dadurch plötzlich Auswirkungen auf Rechnungen, Steuerprozesse und Buchhaltungsdaten haben.

Ricardo erklärt, wie sein Team diesen Monolithen unter laufendem Betrieb schrittweise ablöst: durch klare fachliche Domänen, eine API-first-Architektur, gekapselte Microservices, Events und möglichst geringe Abhängigkeiten. Geschäftskritische Funktionen werden teilweise parallel in alter und neuer Architektur ausgeführt, damit Abrechnungen, Dokumente und Daten bis auf den Cent miteinander verglichen werden können.

Doch die größte Herausforderung ist aus Ricardos Sicht nicht allein die alte Architektur. Es fehlt zunehmend an Entwicklern, die technische Grundlagen wirklich verstehen.

Ein System kann auf den ersten Blick funktionieren und trotzdem schlecht gebaut sein. Eine API, die bei jedem Fehler lediglich einen HTTP-500-Status zurückgibt, erschwert nicht nur Menschen die Fehlersuche. Auch eine KI kann nicht erkennen, ob eine Ressource fehlt, ein Parameter ungültig ist oder ein fachlicher Fehler vorliegt.

Ricardos Warnung:

Wir werden künftig weniger Code selbst schreiben. Gleichzeitig brauchen wir mehr Menschen, die diesen Code beurteilen können. Wenn Unternehmen heute nicht in Junioren investieren, fehlen ihnen morgen die Seniors und Architekten.

Bei arendicom wird KI trotzdem längst produktiv eingesetzt. Ricardo berichtet von erheblichen Effizienzgewinnen bei Dokumentation, Codeerzeugung, Datenprüfung und Softwaretests. Eine Funktion kann unter guten Voraussetzungen in weniger als drei Minuten entstehen. Aus 15 manuell entwickelten Testfällen können mit KI rund 50 sinnvolle Tests werden.

Der entscheidende Punkt: Die eigentliche Arbeit verschwindet nicht. Sie verlagert sich.

Je schneller die KI programmiert, desto wichtiger werden:

•  Requirements Engineering, 
•  sauberer und gezielter Kontext, 
•  Architekturentscheidungen, 
•  Teststrategie, 
•  Qualitätskontrolle, 
•  technisches Grundlagenwissen, 
•  und die Fähigkeit, Risiken zu verantworten. 

Ricardo erklärt außerdem, warum arendicom mit vergleichsweise niedrigen KI-Kosten von ungefähr 20 bis 50 US-Dollar pro Entwickler und Monat auskommt, welche Rolle strukturierte Markdown- und Steering-Dateien spielen und weshalb Unternehmen auch ihr Prompt Engineering regelmäßig überprüfen sollten.

Du erfährst in dieser Folge:

•  wie technische Schulden zu konkreten Businessrisiken werden, 
•  wie man einen Legacy-Monolithen unter laufendem Betrieb modernisiert, 
•  warum klare Domänengrenzen wichtiger sind als möglichst viele Microservices, 
•  wie paralleler Betrieb und automatisierte Tests Migrationsrisiken reduzieren, 
•  welche Grundlagen Entwickler auch im KI-Zeitalter verstehen müssen, 
•  warum KI den Engpass vom Schreiben zum Beurteilen verschiebt, 
•  wo Agentic AI in der Softwareentwicklung tatsächlich Produktivität schafft, 
•  weshalb gutes Requirements Engineering Kosten und Iterationen reduziert, 
•  und warum ein CTO scheitert, wenn er versucht, schlauer zu sein als seine klügsten Köpfe. 

Eine Folge für CTOs, Softwarearchitekten, Tech Leads, Engineering Manager und Entwickler, die KI nicht nur zum schnelleren Produzieren von Code einsetzen, sondern langfristig tragfähige Softwaresysteme bauen wollen.

Transcript

SPEAKER_00 0:00

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 Deutsche, externer CTO, CTO Coach und Gründer der Becoming CTO Community. Und heute spreche ich mit Ricardo Cescon. Er ist der CTO von Arrendicom und wir sprechen über die Modernisierung einer 15 Jahre alten Commerce-Mittelware. Wir übersprechen ü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, Ricardo. Herzlich willkommen.

SPEAKER_01 0:47

Allerdings, vielen Dank und schönen Gruß nach Hamburg, Philipp.

SPEAKER_00 0:53

Danke dir, ich danke dir. Ja, du beschreibst dich, zumindest beim 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 auch sogar schon von der CTO-Rolle heutzutage in Hindsight.

SPEAKER_01 1:17

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 Systemen, wo man wirklich noch hardwarennah 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 Softwareingenieur, als CTO und es schärft vor allem den Blick aufs Wesentliche. Sehr gut.

SPEAKER_00 2:18

Und du bist ja jetzt auch schon einige Jahre CTO bei Rendycom, ich glaube seit 2021. Richtig. Was war denn der größte Perspektivwechsel vom, du warst ja vorher auch technischer Experte bzw. Tech-Lead und bist dann in die Unternehmensführung ja mit aufgestiegen als CTO?

SPEAKER_01 2:37

Ja, ganz wichtig an der Stelle ist, Technik nicht als Selbstzweck zu verstehen, sondern wirklich hin zum kompromisslosen Business Value. Das ist eins der entscheidendsten Dinge eigentlich an der Stelle.

SPEAKER_00 2:52

Was bedeutet das für dich so im Tagesgeschäft? Woran machst du das dann fest? Hast du ein Beispiel?

SPEAKER_01 2:58

Es ist vor allem ganz wichtig, dass die technische Notwendigkeit für Nicht-Techis 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.

SPEAKER_00 3:25

So geht es viel auch wieder um Brückenbauen, 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?

SPEAKER_01 3:46

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.

SPEAKER_00 4:28

Was bedeutet das konkret?

SPEAKER_01 4:29

Das bedeutet konkret, die Marken, die Großen, haben den entscheidenden Vorteil mit Arrendicom, dass wir Merchant of Records sind, sprich wir der rechtliche Verkäufer zum Ekunden. 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. Wir machen 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.

SPEAKER_00 5:32

Und wer ist denn so der typische Kunde von euch?

SPEAKER_01 5:34

Ein typischer Kunde wäre beispielsweise Picœur im Reitsport.

SPEAKER_00 5:38

Ah, Picœur, okay. Ich bin im Reitsport nicht bewandert, deswegen mir sagt der Name gar nichts. Aber alle Reitsport-Fans dürfen sich hoffentlich nicht auf die Füße getreten fühlen. Ihr gebt ja das kundenseitige Shop-Geschäft an eine Partneragentur ab und fokussiert euch dann schon vollständig auf die Mittelbeere. Das hast du zumindest auch gerade nochmal so gesagt. Was war denn der Auslöser für diese Entscheidung?

SPEAKER_01 6:03

Schuster, bleib bei deinen Leisten, würde ich sagen. Das war eigentlich der entscheidende Auslöser. Nein. 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 Randicom 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 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 tieferes Know-how gerade im Shop-Bereich haben, einfach mit ein.

SPEAKER_00 7:37

Zum Beispiel für so einen Partner, was der mitbringen muss, in welchem Bereich er dann Services oder Lösungen anbietet?

SPEAKER_01 7:44

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. Klar gibt es auch Agenturen, die können beides genauso gut.

SPEAKER_00 8:02

Was war denn der Auslöser für die Entscheidung?

SPEAKER_01 8:05

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.

SPEAKER_00 8:18

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?

SPEAKER_01 8:44

Genau, wir orchestrieren im Endeffekt das gesamte Ökosystem und spielen wirklich Mittelware in alle Richtungen, Size, ERP, Postsystem, Shopsystem und versuchen halt diesen eigentlichen Business Value, der für die Marken steht, abzubilden.

SPEAKER_00 9:01

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.

SPEAKER_01 9:21

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. Das 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 da Ansprechpartner an der Stelle sind und die rechtliche Vertretung im Endeffekt übernehmen, hat die Marke eigentlich den Vorteil unter Händler, es gibt am Ende des Monats eine einzige Hutschrift, die kommt von uns und Händler und Marke bekommen ihr Geld.

SPEAKER_00 10:29

Wie stellst du dann damit im Hintergrund sicher? Also ich meine, das wird ja für den Kunden ist das natürlich einfach und convenient, er zahlt dafür halt einen gewissen Preis, aber hinten raus kann das natürlich auch komplex werden, wenn du halt ein Riesennetzwerk an verschiedenen Agenturen, anderen Servicedienstleistern und so weiter 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 da hinten dran ist, dass das nicht zu viel wird, dass das managbar bleibt. Das stelle ich mir aus Portfolio-Managementssicht nicht einfach vor.

SPEAKER_01 11:07

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.

SPEAKER_00 11:43

Und ihr seid, also aus meiner Sicht wird Arendom ö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 Plattformfirma?

SPEAKER_01 12:06

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.

SPEAKER_00 13:02

Ja, auf dem Weg dahin haben wir ja im Vorgespräch auch drüber gesprochen. Galt es ja auch in 15 Jahre alten Monolithen zu modernisieren. Wie macht man das ohne Geschäft anzuhalten oder ohne das laufende Geschäft zu kannibalisieren oder dass es darunter leidet?

SPEAKER_01 13:22

Ja, hier ist vor allem ganz entscheidend, man braucht eine vernünftige Migrationsstrategie. Bei uns ist die Migrationstrategie.

SPEAKER_00 13:30

Das klingt ja mal so einfach auf dem Papier, ne? Da braucht man einfach nur eine vernünftige Migrationsstrategie. Ja, super. Aber ihr macht das ja anscheinend gut, ne? Also was erzähl mal.

SPEAKER_01 13:40

Ja, 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 Erfahrungen über 26 Jahre in der IT mehrfach gemacht habe, 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 Funktionsstreams 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. Weil 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.

SPEAKER_00 16:05

Ich kann mir vorstellen, dass der einer der schwierigsten, also du hast das am Anfang gerade so schön beschrieben, man muss die Domain 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 Domain 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?

SPEAKER_01 16:38

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.

SPEAKER_00 16:57

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?

SPEAKER_01 17:13

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 wertgelegt worden ist und nicht auf die Qualität wurden.

SPEAKER_00 17:40

Schnelligkeiten Entwicklung, meinst du?

SPEAKER_01 17:42

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.

SPEAKER_00 18:34

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 sag's jetzt einfach mal so, verbrochen haben, wobei sie nicht die alleinige Verantwortung dafür tragen, weil natürlich man auch sehr auf der, wie bei euch auch, auf die Zeit auch 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 JBoss geforgt und hat im Endeffekt Funktionen in JBoss eingebaut, die dann da über sehr viele Jahre drin hingen, die dann dazu geführt haben, dass man nicht mehr von der J-Boss-Version weiter migrieren konnte. So, 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 wäre halt super anstrengend gewesen. Also ich kann, ich verstehe, wie man in solche Situationen kommt und wie viele, dass es im Endeffekt die technischen Schulden und die Zinsen sind, die man dann irgendwann zurückzahlen muss. Wie sah denn am Ende für am Ende des Tages dann eure Migrationsstrategie aus? War das, du hast jetzt ja schon erzählt, hin zu Microservices, aber war das so eine schrittweise Ablösung? Habt ihr Strangler-Pattern sehr viel eingesetzt? So, nach welchen fachlichen Grenzen habt ihr das denn geschnitten und wie seid ihr vorgegangen?

SPEAKER_01 20:18

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 Wulstan-Code, wirklich mit einer vernünftigen Kapslung wirklich in einzelne Teilbereiche zu kommen. Weil das verhindert genau auch solche Probleme, wie du eben beschrieben hast. Sobald man eine vernünftige Kapslung hat und beispielsweise Stock nur Stock macht, Produkt nur Produkt macht, Abrechnung nur Abrechnung macht und das einzelne Microservices sind, vor allem in dem Text-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 Nullabhängigkeiten hat, oder möglichst gegen Nullabhängigkeiten hat, weil die ein oder andere Library hat man immer als Abhängigkeit, hast du einfach da auch die Chance 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. Die Chance haft man nicht.

SPEAKER_00 21:49

Wie stark habt ihr das denn umgesetzt? Also gerade so diese Aufteilung von den verschiedenen Microservices, da gibt es ja viele Anti-Patterns, in die 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 einen Microservice gebaut, der eigentlich seinen Namen nicht wert ist? Du wärst ja nicht der Erste, mit dem das passiert.

SPEAKER_01 22:28

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.

SPEAKER_00 23:23

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, paralleler Betrieb?

SPEAKER_01 23:49

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, lasst 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.

SPEAKER_00 24:46

Ja, welche Kennzahlen sind denn für dich dann wichtig, auch um zu gucken, ob die Modernisierung wirklich gelungen ist?

SPEAKER_01 24:55

Ja, also die Kennzahlen an der Stelle, die beste Kennzahl ist immer die Kundenzufriedenheit als Dienstleister. Das ist wirklich das A und O.

SPEAKER_00 25:08

Könnte ich auch sagen, Umsatz.

SPEAKER_01 25:11

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.

SPEAKER_00 25:22

Was ist mit Engineeringlastigen KPIs? Was ist dir da wichtig, um das so anzuschauen? Also sowas wie Lead Time, Cycle Time, I don't know.

SPEAKER_01 25:30

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 gekapert. Das sind so Sachen, die die Effizienz an der Stelle, wenn du irgendwie ein neues Feature implementierst, wo du vielleicht alleine bei 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 haben Features im Vergleich, wie lange dauern Features heute im Vergleich zu früher.

SPEAKER_00 26:22

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?

SPEAKER_01 26:48

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 eine Art.

SPEAKER_00 27:23

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.

SPEAKER_01 27:30

Ja, aber das ist, das ändert ja nichts am Grundproblem.

SPEAKER_00 27:34

Nö, natürlich nicht.

SPEAKER_01 27:36

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 da ist das beste Beispiel, kannst du auch mit der einen oder anderen KI ausprobieren. Je nach Prompt wird ein ähnlich schlechtes Ergebnis, wie bei manchen Junioren rauskommen, dass beispielsweise eine API pauschal bei jedem Fehler ein HTTP 500 liefert. 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 AP ü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.

SPEAKER_00 28:59

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. 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.

SPEAKER_01 29:28

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. Da muss man auch ins Auge sehen. Aber wir brauchen immer mehr eigentlich 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.

SPEAKER_00 31:10

Das ist richtig. Aber welche technischen Grundlagen oder welches technische Basiswissen ist denn für Softwareentwickler im Jahr 2026 trotz allem und also trotz KI und allem, was das 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?

SPEAKER_01 31:36

Nee, 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 hardware-nahe Grundlagen kann. Wenn ich aber einen Webentwickler habe, erwarte ich sehr wohl, dass ein Grundverständnis für einen TCP- und HTTP-Stack mit sich bringt. Zumindest weiß, was sind Pakete sind, 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.

SPEAKER_00 32:27

Jetzt ist aber, jetzt hast du Beispiele genannt, die halte ich auch für richtig. Das sind aber Einzelfälle, ne? Und du sagst, du siehst ja selber, die sind abhängig auch 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 dem 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 muss ich an die Themen ran, dann kann ich ja nicht immer anschauen und muss sagen, ja, wenn der jetzt mal Junior-Entwickler werden, äh, Frontend-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. Also so wirst du ja nicht die Leute durchs Studium bringen, sondern welche High-Level, wenn du es mal irgendwo auf ein, zwei Abstraktionsleveln drüber schaust, hast du da ein Verständnis entwickelt, was du sagen willst, das muss mit rein und das kann man auch weglassen mittlerweile?

SPEAKER_01 33:22

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.

SPEAKER_00 33:49

Dann lass uns mal das Thema Artificial Intelligence KI mit reinnehmen. Ihr habt gesagt, ihr habt KI-gestützte Entwicklung erst dann ganz bewusst eingeführt, als Qualität und Kosten für euch stimmen. Das ist erstmal, ich glaube, vom Ansatz her sehr gut, also zu gucken, wie viel Token verbrauche ich denn, was kostet mich das denn und dass ich nicht mehr irgendwie jetzt ein 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 Reife gerade erkannt und irgendwann beschlossen, jetzt können wir das Ganze auch für Codegenerierung einsetzen?

SPEAKER_01 34:35

Ja, also wir haben immer wieder quartalsweise eigentlich das Thema KI für uns als Sparing-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 kosten. 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.

SPEAKER_00 36:00

Ja, was habt ihr für Effizienzgewinne bisher erreicht?

SPEAKER_01 36:05

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 Binnenminuten.

SPEAKER_00 37:20

Ich hätte sogar gesagt, ich finde die Einschätzung, dass das 400% mehr sind. 400% ist ja eigentlich eine Vervierfachung. Das fast schon konservativ, das sozusagen, also wenn die AI das schreibt.

SPEAKER_01 37:35

Ja, also ich muss sagen, wir haben festgestellt, man muss es immer noch ein Stück weit nachkontrollieren.

SPEAKER_00 37:42

In der Qualitätssicherung der Dokumentation, da geht wieder Zeit drauf.

SPEAKER_01 37:45

Verlierst du wieder verlierst du wieder einen Prozentsatz, ja, ganz klassisch. Weil wir haben da mehrfach festgestellt, wenn man es nicht nachkontrolliert, du hast immer noch einen ganz kleinen Bruchteil an 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.

SPEAKER_00 38:18

Ja, 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? Was stimmt nicht mit euch? Also, weil ich, 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 Agent gestü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?

SPEAKER_01 39:22

In der Entwicklung finde ich es relativ entscheidend. Jetzt gar nicht mal 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.

SPEAKER_00 40:18

Ja, absolut.

SPEAKER_01 40:19

Wo es aber dann wieder spannend wird, der Zeitgewinn oder die Effizienz an der Stelle vom Erzeugen des Codes, die wird relativ viel durchs 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 dem Business Case ein Stück weit für einen Testfall verstehen muss. Der Punkt ist aber der, wenn der klassische gute Entwickler insgesamt bei einer Funktionalität auf 15 Tests kommt, findet dir die KI nachfolgend durch das eigene Testen der KI. Die schreibt dir den Testfall, testet den Testfall und findet dir meistens neue Testfälle. Und da kommt eigentlich der Effizienzgewinn, weil aus 15 Testfällen vom Softwareingenieur 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.

SPEAKER_00 41:42

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?

SPEAKER_01 41:57

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?

SPEAKER_00 42:16

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 es auch eine, dass mir irgendwann, 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, weil ich vielleicht doch eine Lane haben möchte, also dann ist die ICD-Pipeline, die die Geschwindigkeit vor Vollständigkeit bevorzugt, aus vielleicht mir bekannten oder aus akzeptablen Gründen.

SPEAKER_01 42:52

Ja, aber da sind wir ja dann schon eigentlich im Bereich Refactoring, ne? 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 Softwareingenieure zusammensetzen, kann man das wieder in Testdomänen unterteilen.

SPEAKER_00 43:15

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?

SPEAKER_01 43:25

Wir kommen wirklich aktuell mit 20 bis 50 US-Dollar pro Entwickler wunderbar weg.

SPEAKER_00 43:36

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?

SPEAKER_01 43:45

Ne, wir nehmen schon wirklich Agentic AI. Wir haben einen sehr niedrigen Token- oder Creditverbrauch 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.

SPEAKER_00 44:25

Also sauber, jawohl, ja, sauberes, 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 da 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 ein 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 aufzublähen 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.

SPEAKER_01 45:43

Ja, man muss da ein bisschen vorsichtig sein. Also, was ich immer wieder sehe, dass viele auch teilweise schlechte Agentec AI benutzen. Ich bin ein wahnsinniger Fan von Kiro beispielsweise, weil es ist erstmal 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 obendrü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 mehr Kosten. Du hast zwar initial vielleicht höhere Kosten, aber wenn du es zulässt, dass ich 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.

SPEAKER_00 47:23

Und ich sehe schon, ihr seid da recht weit, indem wie ihr das angeht, auch den Ansatz erst Kosten und Qualität kontrollieren zu können, bevor man den Wasserhahn auftret 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 scharrst schon mit den Hufen, um die beantworten zu dürfen. Sehe ich das richtig?

SPEAKER_01 47:56

Absolut.

SPEAKER_00 47:57

Sehr schön. Modularer Monolith oder Microservices?

SPEAKER_01 48:01

Microservice mit absolut sauberer Domänentrennung.

SPEAKER_00 48:05

Ah, sehr schön. Bild bei oder Partner?

SPEAKER_01 48:09

Alle drei. Zum richtigen Zeitpunkt, zum richtigen Zweck benutzen.

SPEAKER_00 48:14

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.

SPEAKER_01 48:24

Muss komplett im Einklang stehen. Ohne Grundlagen, Fundament wird die KI dir nichts bringen mit Grundlagen, Fundament ist es ein absoluter Turbo.

SPEAKER_00 48:36

Zumal dürfen wir ja auch nicht vergessen, EU Cyber Resilience Act kommt bald. Viel Spaß damit, liebe Vibecoder. Wenn ihr das alles, ja, ich meine das ernst. Also da ja, du kannst ja nicht jede App da irgendwo hinstellen, du musst ja irgendwo auch sauber aufzeigen können, was du da machst und wie und wieso, weshalb, warum. Das ist nicht, die Anforderungen werden steigen.

SPEAKER_01 48:58

Ja, es flacht vor allem mal diesen Hype ab und dieses mittlerweile entstandene Buzzword.

SPEAKER_00 49:05

Im Vibecoding ist fast schon ein Schimpfwort geworden, ne? Absolut. Welches Protokoll sollte jeder Backend-Entwickler wirklich verstanden haben?

SPEAKER_01 49:13

Das, was er für sein tägliches Brot braucht, in unserem Fall HTTP.

SPEAKER_00 49:18

Na klar, wenn du im Web unterwegs bist, geht nichts über geht nichts ohne HTTP.

SPEAKER_01 49:25

Wird schwierig.

SPEAKER_00 49:26

Bitte vervollständige den Satz. Ein CTO scheitert, wenn.

SPEAKER_01 49:30

Wenn er versucht, schlauer zu sein als seine schlauesten Köpfe.

SPEAKER_00 49:34

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, aber ja. Ricardo, 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 Painpoints dahin. Ich finde es auch schön, von dir zu hören. Also mich wieder bestätigt zu sehen, dass es 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.