# Agentic AI Shifts CTO Focus to Verification

**Podcast:** Becoming CTO Secrets
**Published:** 2026-09-15

## Transcript

Hallo und herzlich willkommen zu Becoming CTO Secrets, dem Podcast von CTOs für CTOs und all diejenigen, die es noch werden wollen.
Ich bin Philipp Deutscher, externer CTO, CTO-Coach und der Gründer der Becoming CTO-Community.
Mein heutiger Gast ist Bendri Batty.
Er ist der CTO der Innovatec AG und verantwortet dort unter anderem IT-Strategie, Softwarearchitektur, Security, Operations.
Und dazu natürlich noch die internationale Entwicklungs- und die Infrastruktur-Teams.
Und das alles in einem hochregulierten HR-Payroll- und Finanzsoftware-Umfeld.
Er baut den Softwareentwicklungsprozess von Requirements Engineering über Design und Implementierung bis hin zur Verification gerade komplett neu.
Natürlich mit Agent TKI und darüber werden wir auch sprechen heute.
Wir sprechen darüber, warum Code dabei zum einfachen Teil werden kann, weshalb die Guardrails unbedingt notwendig sind.
um Geschwindigkeit überhaupt erst zu ermöglichen und wie sich dadurch die Rolle des CTOs natürlich auch verändert.
Bendry, herzlich willkommen.
Hi Philipp, danke für die Einladung.
Ich freue mich total, hier zu sein.
Ich mich auch tatsächlich, ich mich auch.
Und vielleicht bevor wir über das Thema AI sprechen, Bendry, was macht denn...
Innovatec eigentlich?
Und vielleicht kannst du uns mal kurz was dazu erzählen, auch welche Rolle Technologie spielt in dem Umfeld des Unternehmens.
Ich habe ja eben angeteasert, Arbeit, Payroll, Gesundheit, Vorsorge, das verbindet ihr alles.
Was macht Innovatec?
Sehr gerne.
Also Innovatec verbindet tatsächlich die drei Domäne, die im Leben eines Menschen sozusagen zusammengehören, aber leider in manche traditionelle Softwarelandschaften in drei Silos verteilt werden, also die Domäne Arbeitsgesundheit.
Vorsorge bzw.
auch Vermögensaufbau bzw.
Vermögen.
Der Anspruch für uns ist sozusagen der Gesamtzyklus, Lebenszyklus eines Arbeitsnehmers auf eine Lösung abzubilden.
Also von der Arbeit in Bezug auf seine Zeit, Lohn, Gesundheit, Russische Vorsorge und Vermögensaufbau.
Technologie ist für uns nicht nur das Beiwerk, ist tatsächlich das Produkt selbst.
Ihre eigentliche Aufgabe ist, wie du vorhin schon gesagt hast, diese drei Domäne zu vernetzen.
Was bedeutet das?
In einem sozusagen in einem durchgehenden Prozess miteinander zu verbunden, sodass die Abwicklung ohne Medienbruch funktioniert.
Also der Wert entsteht nicht sozusagen in den drei verschiedenen Silos zu sein, sondern in nahtlos Zusammenspiel zwischen den drei Domänen.
Übrigens, das ist tatsächlich nicht nur ein Schweizer Thema.
Also wir betreiben einen europäerweiten agierenden Pensionsfonds in Luxemburg registriert.
Also mit Deutschland als Betriebsstätte.
Einfach nur als Hinweis, das ist unsere Start-up-Modus-Firma sozusagen.
Das zeigt, dass die Vorsorge-Domäne nicht an eine Landesgrenze aufhört, sondern grenzüberschreitenden Nutzen stiften kann.
Genau.
Sehr schön.
Du kommst ja auch selber aus einer sehr technischen Welt.
Du hast, glaube ich, selber auch als Engineer angefangen und bist dann in die CTO-Rolle reingewachsen.
Wie ging denn dieser Weg?
Das ist ja so die Blaupause, von der alle Engineers träumen, die vielleicht Ambitionen haben, in so eine Richtung zu wachsen.
Vom Engineer zum Director, zum Vice President, zum CTO.
Wie war dein Weg dahin?
Ja, mein Weg tatsächlich bewusst sehr, sehr technisch geblieben, bevor er bereit wurde.
in Kasselslautern studiert.
Vielleicht kennt man die Stadt.
Du kennst sicherlich die Stadt.
Ich habe ja auch dort studiert.
Haben wir ja festgestellt, dass wir beide eine Gemeinsamkeit haben.
Genau, so ist es.
Da habe ich Elektrotechnik studiert und komme ursprünglich aus der Hardware-nahe, also Embedded-Systeme.
Also zum Beispiel C++ ist zum Beispiel, da habe ich angefangen tatsächlich meine Softwareentwicklung in der Hardware-nahen Bereich zu entwickeln.
Und da habe ich tatsächlich sehr früh an ungewöhnlichen sogenannten Weblösungen gearbeitet, in einer Zeit, wo man noch sehr tief in die Maschine müsste.
Danach ging das in die Navigationssoftware in Karlsruhe und in die Finanzwelt.
Also DAX-Index-Systeme in Frankfurt habe ich bestreut bei der deutschen Börse.
Dann später in eine grenzüberschreitende Index-Plattform bei Indexium in der Schweiz.
Das ist eine Joint-Fanchise zwischen deutschen Börsen und SIX zu der Zeit.
Und danach ein Startup für Maschinen-Learning-basierte Portfolio-Management-Systeme.
Der Schritt tatsächlich in die CTO-Rolle war weniger ein Bruch als eine Erweiterung der Verantwortungsradius.
Also von der Frage, wie baut man das richtig, also wie baue ich das richtig, zu einem, wie baue ich eine Organisation so, dass es dauerhaft richtig bauen kann.
Also bei Innofatic bin ich seit April 21.
dabei.
Und was bedeutet die CTO-Rolle für dich heute?
Am Anfang war die CTO-Rolle für mich so, dass der CTO das schwierigste Problem lösen soll, muss.
Heute verstehe ich fast umgekehrt.
Meine wichtigste Aufgabe ist, System zu bauen, in dem gute Entscheidungen getroffen werden können, ohne dass ich in jedem einzelnen sitze.
Was ich tatsächlich unterschätzt habe, war, wie viel CTO-Arbeit eigentlich Übersetzungsarbeit ist.
Also zwischen dem Business und Engineering, zwischen der Regulierung und Machbarkeit, zwischen der Geschwindigkeit und Kontrolle.
Allerdings, der technische Anteil bleibt sehr entscheidend, weil ohne belastbare technisches Urteil kannst du auch nicht Risiko und Kosten richtig bewerten.
Aber am Ende, der Hebel liegt immer noch an der Klarheit, Leitplanken und Vertrauen.
Und nicht im eigenen Commit, sozusagen im eigenen Code.
Wie lange hast du selber gebraucht, um das rauszufinden?
Also auch, dass du viel diese Vermittler- und Übersetzerrolle einnehmen musst?
Also der erste Teil hat, also es hat mich schon lange gebraucht, weil ich komme ja aus diesem Bereich, wo ich selber entwickeln musste, selber Hand drauflegen musste.
Ich musste verschiedene, sagen wir mal, Drawback erstmal erleben in der Firma, bevor ich verstehe, okay, ich muss ganz anders agieren.
Ja, das mit Zeit kann ich nicht sagen, aber vielleicht ein Jahr, eineinhalb, wo ich dann erst verstehe, ich muss das anders agieren.
Wir kennen es jetzt auch schon eine ganze Weile und wir haben auch schon viel diskutiert über das Thema Agentic AI, AI-Strategien.
Wir haben natürlich auch festgestellt, in vielen Unternehmen da draußen, da ist das Thema AI-Strategien mehr so ein, ja, wir verteilen Co-Pilot-Lizenzen und nennen das dann AI-Transformation.
Du hast selber auch eine AI-Strategie entwickelt für Innovatik.
Und wo begann eigentlich eure Transformation?
Genau, wie du schon sagtest, Lizenz zu verteilen ist der einfachste und ich würde sagen am wenigsten wirksame Teil davon.
Damit bekommt man sozusagen autocomplete auf Steroiden.
Also wir kriegen so nette Produktivität im kleinen Rahmen, im kleinen Bereich, aber natürlich kein neues System.
Unsere eigentliche Transformation begann in dem Moment, wo wir realisiert haben, dass AI nicht nur einen Weg zeigt einzelnen Entwickler zu betrachten und angefangen haben, tatsächlich die Entwicklungsprozesse selbst als AI-Natives neu zu denken.
Das war unsere eigentliche Transformation.
Der Wendepunkt für uns war die Erkenntnis, dass wenn Code fast beliebig schnell erstellt werden kann, verschiebt sich natürlich der Eng fast nach vorne, nach der Spezifikation, nach dem Design und nach der Verifikation sozusagen.
Also nicht schneller tippen, sondern schnell präziser denken und zuverlässig prüfen.
Das ist für uns am wichtigsten.
Daher haben wir dann unsere AI-STLC, also AI Software-Divarm Lifecycle, erstellt mit den vier Phasen.
Spezifikation, Design, Implementation und Verifikation mit klaren Artefakten, Leitplanken, auch die terminischen Kern und die kritische Entscheidung am Ende auch treffen kann und nicht dem Modell überlässt, sozusagen.
Wir haben jetzt in Unternehmen...
Haben wir am Anfang auch festgestellt, naja, wenn Engineering so viel schneller ist, dann ist klar, dann verschiebt sich der berühmte Engpass nach vorne.
Aber dann haben wir auch vorne festgestellt, um Spezifikation und Design und sowas zu machen.
Das lässt sich ja eigentlich auch ganz gut mit AI lösen, beziehungsweise dann ist ja der Engpass doch wieder nicht vorne, sondern er wandert wieder weiter nach hinten, nämlich zum Teil der Verification.
Ist das auch bei euch so, dass das der...
der schwierigste und auch der anspruchsvollste Teil in der Erstellung eines AI SDLC ist?
Ja, also definitiv.
Ich meine, wir müssen ja am Ende des Tages in der Spezifikation die Dinge so, die Anforderungen oder das Business-Problem so übersetzen, mit einer präziseren, prüfbaren Anforderung spricht.
Wir müssen...
am Ende eine Acceptance-Kriterie machen, mit dem er das prüfen kann.
Und das ist eben der Punkt, wo es auch am Ende schwieriger ist.
Warum ist das so?
Weil du musst ja in der Inspektionsphase, also am Anfang, du musst ja erstmal feststellen, hey, welchen Teil habe ich jetzt nicht berücksichtigt?
Das ist nämlich auch ein Thema, wo wir dann alles, was wir nicht berücksichtigen, füllt das AI rein.
Da müssen wir sozusagen alles auf Oberfläche nehmen.
Wir müssen mit Acceptance-Kriterien schaffen, wir müssen das verifizieren, damit das am Ende rauskommt, was man eigentlich vorgestellt hat.
Das ist eben unsere Erfahrung auch damit jetzt.
Du hast ja zusätzlich auch noch die These vertreten und hast das jetzt gerade eben auch nochmal bestätigt, dass ja gutes Requirements Engineering automatisch wichtiger werden muss, wenn der Code hintendran viel schneller entsteht.
Wie stellst du, also was muss denn so eine Spezifikation dann leisten?
Vor allen Dingen auch vor dem Hintergrund, dass du ja andere Dinge auch absichern musst, wie Scope Creep und dass die eigentlichen Tasks nicht auf einmal wieder viel, viel größer werden.
Also die Versuchung liegt ja nahe, auch für einen Product Manager, wenn die AI einem vorschlägt, ach, zu dem Feature, dann solltest du noch das und das und das bedenken und der hat denkt, ja, ist ja super und dann ist das auf einmal ein Feature, was relativ klein und überschaubar gewesen wäre, ist auf einmal sehr, sehr groß.
Das kann ja auch nicht im Sinne des Erfinders sein, oder?
Nein.
Also das ist so.
Also wenn man das nochmal zurückdenkt, früher ohne AI, also ohne AI mit der Spezifikation, hast ja normalerweise in einem normalen Softwareentwicklung-Modus ist es so, du hast Commons Engineering oder sogar Entwickler, der erfahren genug ist, sprich mit dem Business und dann gibt das sozusagen ein gemeinsames Verständnis, wie das Ding gebaut werden sollte und die Lücken, also Spezifikationslücken, wird gefüllt durch die Erfahrung von Entwicklern oder von demjenigen, der sehr lange im Unternehmen das ganze Domäne schon kennt.
Und mit dem AI, ist es auch dasselbe, nur wenn man das nicht präzise genug sagt, was man will, oder zu viel sagt, was man will, entsteht natürlich die Lücke noch größer und AI füllt die Lücken aus Selbstbewusstsein.
Das hat man ja auch schon gesehen, das hast du vielleicht auch schon die Erfahrung gemacht.
Dann hast du sozusagen ein Konstrukt gebaut, der sehr effizient funktioniert mit einer Fälleannahme, sozusagen.
Also im Prinzip eine gute Spezifikation muss der muss prüfbar sein in Bezug auf, brauchen wir das wirklich?
Ist es das, was Business auch wirklich braucht und löst das unser Problem?
Es muss vollständig genug sein, damit die kritischen Entscheidungen nicht dem Modell überlassen werden.
Und es muss explizit machen, was nicht erlaubt ist.
Das ist sozusagen die Spezifikation am Ende.
ist nicht mehr die Vorstufe des Engineering, wie man es so vorher kennt, sondern der eigentliche Engineering Act, wie du vorhin auch schon gesagt hast.
Und wenn du jetzt so vor eurem SDLC gestanden bist, noch bevor ihr jetzt flächendeckend AI eingeführt habt, wo fängst du denn da an?
Also wenn du über das Thema Einführung von Agentec AI redest, fängst du dann beim Requirements Engineering an, fängst du beim Coding an oder wo genau fängst du an?
Sagen wir mal, wir fangen da an, um zu verstehen, okay, wie ich vorhin schon gesagt habe, wo ist das Business-Problem?
Was müssen wir eigentlich jetzt lösen?
Also im Prinzip schon die Vorstufe, wo das Produkt und zusammen mit dem Engineering zusammensitzen und sagen, okay, was für ein Problem wollen wir lösen?
Wie normal in Software Development Lifecycle.
Und dann fängt man an, sozusagen die Guardrails zu definieren, was muss eigentlich, das Ding alles können und nicht können.
Und wenn man das damit anfängt, dann erstellt man die ersten Use Cases, also Spefikationsphase.
Die ersten Use Cases, in der Use Cases erstellt wird, Use Cases 1, 2, 3, dann iteriert man das zusammen mit dem Business und sagt, ist das ungefähr das, wie man sich vorstellt.
Wenn das erstellt ist, Dann kann man die restlichen Sachen machen.
Sprich, wir müssen die Architecture Description Records auch machen.
Also wir müssen die Planung machen.
Wie soll das Ding wirklich technisch aussehen?
Und dann danach kann man anfangen, die ersten Codes zu generieren.
Sagen, okay, so wird es funktioniert.
Und nicht vergessen, wie ich vorhin gesagt habe, innerhalb von dem Use Case muss natürlich die Acceptance Kriterien da sein, damit ich nachher bei der Verifikation auch das verifizieren, was auch wirklich am Ende Business bringt.
Also, wenn du so siehst, das ist nicht anders als die damalige Softwareentwicklung, nur es braucht von dir noch mehr Präsidation in allem, was du tust.
Ja, ich habe mich gerade gefragt, ist das so wirklich davon abhängig, was du jetzt auf der Businessseite machen möchtest?
Also ja, grundsätzlich schon.
Aber der SDLC selber ist ja erstmal ein Engineering-Prozess, der gilt für die gesamte Company und der gilt für die gesamte Company für eine möglichst lange Zeit, damit er reproduzierbar ist und nach den immer gleichen Kriterien erfolgt und du die Lieferqualität sicherstellen kannst.
Jetzt hast du natürlich pro neues Produktfeature hast du vielleicht neue Business-Anforderungen, aber die sollten ja nicht dafür zu führen, dass du ständig deinen Prozess anpasst.
Richtig?
Nein.
Nein, der Workflow soll immer gleich bleiben.
Das muss gleich bleiben, weil sonst kannst du nicht das Ganze reproduzierbar machen.
Weil der Anspruch ist es ja auch so, dass gewisse Business-Anforderungen, die du heute bekommst, wird ja auch weiterentwickelt.
Man bekommt sie zurück, man entwickelt sie weiter, existiert weitere Erweiterung eigentlich von den Newscasts, die du schon definiert hast.
Wenn das existiert, dann musst du dafür sorgen, dass mit deinem Workflow alles, was vorher gemacht wurde, auch sauber versioniert in deinen Requirements.
Dass du auch nachvollziehen kannst, was ändert sich eigentlich dort.
Also diese Nachvollziehbarkeit präziser Formulierung ist das A und O.
Das ganze Coding, wie wir vorhin schon gesagt haben, ist zweitrangig.
Wie stellst du dann die Leitplanken, die Guardrails, wie auch immer du die benennen möchtest, wie stellst du dann sicher vor?
dass die das so einschränken, dass du wirklich am Ende eine bestimmte Qualitätslevel sicherstellen kannst?
Die Guardrails oder die Leitplanken für uns ist das, also ich würde mal sagen, wir sind ja noch nicht absolut erfahren jetzt in dem Bereich.
Wir haben erst Anfang des Jahres das Ganze begonnen, wir haben mehrere Applikationen damit schon gebaut, das funktioniert jetzt sehr gut.
Der Proof auf große Projekte kommt noch.
Also deswegen bin ich gespannt in zwölf Monaten, was da kommt, weil wir müssen sicherlich noch die ganzen Workflow weiter erweitern.
Aber im Prinzip ist es so, dass wir die komplette Artefakte, was wir brauchen, von Anfang an definieren.
Wir müssen die Stacks, die wir brauchen, von Anfang an definieren.
Wir müssen die Architektur schon wissen, okay, mit welcher Architektur will ich arbeiten?
Hexagonale Architektur.
Layer-Architektur oder andere Architektur.
Ich muss den Entscheidungsraum sozusagen für die AI so begrenzen, damit die Dinge nicht subtil schief gehen können.
Und Guardrails, die zum Beispiel überall verwendet werden sollen und immer wieder die gleiche Entscheidung trifft, die muss ich einbauen.
Aber ich muss natürlich aufpassen, dass gewisse Guardrails nicht meine sagen wir mal, meine Dynamik innerhalb von der Software auch beeinträchtigt.
Es gibt ein Guardrails, die sehr kontextabhängig sind.
So, hey, der funktioniert zwar in dem Kontext A, aber nicht im Kontext B.
Und das muss man sehr, sehr präziser formulieren, in welchem Kontext man sich bewegt eigentlich von Anfang an.
Ja, und ihr seid ja auch in einem sehr hochsensiblen Umfeld unterwegs.
Du hast das ja eben selber das Feld aufgemacht.
Es gibt Personendaten, es gibt Lohndaten, Versicherungsdaten, Finanzdaten und so weiter und so fort.
Welche Regeln gelten denn für Artificial Intelligence in genau einem solchen Umfeld, dass du weißt überhaupt, was kann ich denn einsetzen, bevor überhaupt ein Entwickler anfängt, die ersten Prompts abzuschicken?
Ist das schon reguliert, reglementiert?
Oder ist aktuell eher noch eine Wild-West-Situation und das kommt erst?
Naja, das ist so.
Bevor irgendjemand bei uns in einen Prompt für die Softwareentwicklung überhaupt macht, derjenige muss sich die Frage stellen, nicht welches Modell nutze ich, sondern wohin fließen die Daten und wer haftet es dafür?
Wie du schon gesagt hast, wir bewegen uns im Bereich von DSG, GDPR und vielen anderen Regulierungen noch, die bei uns sind.
Wir müssen sehr, sehr, sehr gut bewerten, wann, welches Tool wir nutzen können und wie fließen überhaupt diese Daten.
Konkret heißt das, wir müssen die Datenklassifikation sehr, sehr gut machen.
Der Anspruch ist, dass wir sagen, dass die echten produktiven Daten, Personendaten, Vorsorgedaten, Vermögensdaten, nicht ungesetzt in irgendein externe Modell gehen.
Wir nehmen natürlich die Modelle, wo wir wissen, dass die Daten exakt diese Voraussetzungen auch erfüllt.
Bis hin sind wir noch am überprüfen, ob wir das selber irgendwann für bestimmte Verarbeitung die Modelle selbst hosten müssen, weil solche Dinge nicht verhandelbar sind.
Da sind wir noch auf dem Weg.
Also wir sind noch am Anfang, wie ich vorhin gesagt habe, wir müssen noch sehr viele Sachen abklären, aber das ist für uns Dinge, die wir klären müssen, weil das klären wir die ganze Zeit, bevor überhaupt der erste Prompt kommt.
Also Prompt ist tatsächlich der letzte Schritt von dem Ganzen.
Alles andere müssen wir vorher klären.
Macht es in der Schweizer Kontext, macht es das Ganze noch schwieriger oder einfacher?
Also ich würde mal sagen, im Schweizer Kontext ist es ja so, dass man dass man alles achten muss, was auch im europäischen Bereich läuft, was man so kennt in Europa.
Plus noch, dass man in der Schweiz gerne so sieht, dass die Daten die Schweizer Bereich nicht verlässt.
Also die Schweiz nicht verlässt oder wenigstens so, dass die unter dem Schweizer Gesetz unterliegt und dass die Infrastruktur tatsächlich in der Schweiz bleibt.
Das ist die, die wir hier als Voraussetzung haben.
Das heißt, eigentlich wird es schwieriger, weil ihr haltet euch nicht nur an die europäischen Richtlinien, sondern auch an die Schweizer Richtlinien, die noch zusätzliche Regularien on top liefern.
Genau.
Aber wir sagen nicht immer, ob es schwieriger ist.
Wir sagen immer, ja, jeder hat seine Herausforderung.
Ich darf das ja sagen.
Aber die Frage ist, das ist ein stark reguliertes Umfeld.
Entsteht daraus dann auch ein Wettbewerbsvorteil, auch für euch, wenn ihr das richtig angeht, auch im Vergleich zu dem, was eure Konkurrenz macht, gerade weil zu Themen wie Vertrauenssicherheit, Nachvollziehbarkeit jetzt immer wichtiger werden, gerade in die Age of AI?
Ja, das ist, glaube ich, ein Thema, der meiner Meinung nach unterschätzt wird, weil am Ende des Tages...
Coding wird immer super schnell sein.
Also das Ganze machst du ganz billig.
Jeder kann sehr schnell irgendwelche Prototype hinstellen und sagen, okay, ich bin da, ich bin voll cool und funktioniert eigentlich mega gut.
Aber am Ende, meiner Meinung nach, derjenige, der sozusagen die mehrere regulatorische Anforderungen belastbar gleichzeitig erfüllen kann in so einem Umfeld, der wird derjenige sein, der sozusagen mehr Vertrauen, am Ende, wie du gesagt hast, Vertrauen bekommen und die Sicherheitsgarantieren kann und vor allen Dingen die Nachvollziehbarkeit, weil du musst immer nachvollziehen, was genau passiert.
Deswegen haben wir auch bei uns so, dass wir sagen, ja, AI hin und her, aber wir haben ja auch gewisse Sachen, wo wir sagen, das können dann nicht in AI gemacht werden.
Wir nennen das so unser deterministischer Kern, das Regelwerk und so weiter.
Auditierbare Spezifikation, die klare Datenklassifikation, das ist Aufwand, den wir noch nebendran treiben müssen, damit AI sozusagen mit diesem determinischen Kern nebeneinander auch sehr, sehr gut funktionieren kann.
Deswegen bin ich auch überzeugt, Regulierung ist tatsächlich ein möglicher Vorteil und nicht nur als Kostenstelle.
Das ist für mich die Wette.
Jetzt wissen wir ja beide, dass...
Eine größere Änderung in einem Unternehmen einzuführen, also einen sogenannten Change auch auszurollen, durchaus ein Kraftakt sein kann.
Und dieser Change, von dem ich jetzt sprichst, der hat ja durchaus große Auswirkungen auf sehr viele Rollen, auf sehr viele Arbeitsprozesse, auf sehr viele Menschen.
Das kann natürlich super durchdacht sein, das kann hervorragend auf dem Whiteboard aussehen und trotzdem kann die Organisation so etwas ablehnen oder es kann...
Das Ausrollen des Changes kann sehr stark verlangsamt werden.
Wie hast du das denn, einen solchen neuen Arbeitsmodus in deine Teams eingeführt, in deine Organisation eingeführt?
Ja, sicherlich nicht per Dekret.
Also was wir versucht haben, ist tatsächlich durch ein Beispiel.
Also ich selber mit einem Senior Engineer von uns versuchen, als Vorbild da zu sein.
Das heißt, wir machen tatsächlich das Workflow, wir implementieren sie in verschiedenen...
Applikation, die kleine Applikation und bewusst zeigen, was der Vorteil ist, wie wir das überhaupt angehen.
Das muss natürlich technisch so sauber gemacht werden, dass die Techniker bei uns natürlich auch akzeptieren können am Ende des Tages.
Natürlich, es gibt immer Dinge, die man verbessern kann hier und da.
Aber das geht darum, dass man am Anfang der Arbeit so machen, ein Beispiel zeigt, wie das funktionieren kann und dann Feedback abholen.
Die Leute sollen ausprobieren.
Die Leute sollen damit sozusagen Freund werden mit diesem Workflow.
Und am Ende des Tages, was ich mir wünsche, weil jeder probiert, mit diesem Workflow zu arbeiten, will ich auch, dass die Feedback uns liefern.
Dass die sagen, okay, das funktioniert bei mir in dem Fall nicht, aber funktioniert hier und da gut.
Und dann fangen wir an, Konsens zu bekommen, wo wir am Ende des Tages natürlich die Vision, dass wir ein super gemeinsamer Framework der wirklich reduziert ist für Innovatik, den wir für unseren Produktions-Dekot in Bezug auf unser Business auch nutzen können.
Ja, ausprobieren alleine ist natürlich ein guter Anfang, aber das reicht ja am Ende des Tages nicht, sondern es braucht auch nochmal neue Fähigkeiten, Fertigkeiten.
Welche siehst du denn, die jetzt gerade in so einem AI-Native-Engineering-Team, was wird gerade wichtiger und was sind sogar Themen, die gerade an Bedeutung verlieren?
Ich würde sagen, wenn man das probiert hat, merkt man ja, okay, meine Arbeit, meine Rolle, die Art, wo ich arbeite, ändert sich.
Weil es gibt ja plötzlich die Kommunikation, die AI stellt eine präzisere Frage, man muss auch präzise antworten.
Das heißt, wichtiger werden, wenn dieses präziseres Denken und präzises Formulieren.
Wir müssen sozusagen die Fähigkeit haben, mit dem AI, eine, ich würde mal sagen, unscharfes, Business-Problem in eine prüfbare Spezifikation zu übersetzen.
Das ist sehr wichtig, oder?
Architektur und Systemverständnis, weil man beurteilen muss, ob das ein Vorschlag im Ganzen passt, das muss da sein.
Und die kritische Review, das ist eine Fähigkeit, generiert im Code zu misstrauen, aber nicht unbedingt bei jedem, sagen wir mal, Pull-Request, alles zu hinterfragen, sondern auch wirklich zum richtigen Stellen auch die generierten Code zu misstrauen.
Und zu sagen, okay, wie mache ich das?
Das sind die Fähigkeiten, die unglaublich wichtig werden.
An Bedeutung verliert natürlich das ganze reine Syntax-Handwerk.
Die mechanische Übersetzung einer bekannten Lösung in den Code oder das Auswendiglernen von diesem Boilerplate.
Aber ich will aber nicht sagen, dass das tiefe technische Verständnis nicht gebraucht wird.
Ganz im Gegenteil.
Man braucht das umso mehr, um AI zu kontrollieren.
Aber der Wert verschiebt sich vom Produzieren zum Urteilen.
Das ist meine Meinung.
Ja, sehr schön gesagt.
Und du hast gerade gesagt, dass Präzision wichtig wird.
Also Präzision in dem, was du formulierst, dass aus einer unscharfen Business-Idee ein präzises Set an Requirements wird.
Das ist das eine, ja.
Aber wie verhindert ihr, dass dann trotzdem lediglich mehr Features produziert werden?
Also wie verhinderst du oder wie stellst du sicher?
dass wirklich mehr Kundennutzen geschaffen wird durch das, was da passiert?
Hast du darauf dann einen direkten Einfluss?
Also ehrlich gesagt, das sind die Sachen, wo ich mir dann auch ein bisschen Angst habe.
Wie ich vorhin schon gesagt habe, wir sind ja erst am Anfang von unserer Journey.
Es gibt schon Aussagen, er macht das billig, lass uns alles bauen, lass uns alles die Feature-Fabrik machen und so weiter, oder?
Aber das ist genau das, wo wir...
genau Anfang der Journey, genau wissen muss, was bringt uns diese Feature?
Können wir genau benennen, was diese Feature uns am Ende bringt?
Oder ist es nur etwas, wo wir sagen, wir probieren mal, ob das funktioniert, ja oder nein?
Also es muss ganz klar für das Produkt-Team und Engineering-Team, hey, das brauchen wir, das implementieren wir auch so.
Das bedeutet, nicht die Menge der Feature sollte, mehr sein in der Zeit, wo man entwickelt, sondern dass wir die Zeit, was man normalerweise vorher länger gebraucht hat, um Zentren davon reduzieren kann, damit man schneller liefern kann, für den Feature, wo man weiß, das braucht der Kunde definitiv.
Also der eigentliche Hebel liegt für mich nicht darin, mehr vom Gleichen zu produzieren, sondern anspruchsvolle Dinge machbar zu machen.
Unsere Vision Zielt genau darauf, nicht mehr Features, sondern den ganzen Geschäftsprozess in die Software zu gießen.
Der Must-Up für uns ist am Ende der Outcome, nicht unbedingt das Output, wenn du so willst.
Ja, schön gesagt.
Ist natürlich in der Theorie alles richtig, aber woran reißt du denn dann ganz konkret, ob eure AI-Transformation wirklich funktioniert?
Also da geht es ja um Themen wie Geschwindigkeit, es geht um Qualität.
Es geht aber auch um Kosten oder wie viel Nacharbeit notwendig ist, um doch nochmal was hinzukriegen.
Es geht aber vielleicht auch um Business, nicht um Business, um Sicherheit.
Wie misst du das?
Wie stellst du das sicher?
Ja, das ist eine sehr, sehr schwierige Frage, das alles jetzt wirklich genau zu sagen, wie wir das am besten messen können.
Aber ganz klar ist, wir müssen versuchen, an allen zu arbeiten.
Sprich, wir müssen schauen, wie...
können alle diese Geschwindigkeit, Qualität, Kosten überhaupt miteinander zusammenkommen, dass wir das am Ende messen können, ob wir das am Ende besser fühlen können als vorher.
Man kann sehr, sehr schnell viel Falsches produzieren.
Deshalb ist es für uns momentan nicht ganz genau, wir wissen noch nicht ganz genau, wie wir es genau am besten messen müssen am Ende des Tages.
Aber wie ich vorhin gesagt habe, am Ende zählt, dass das, was wir versprochen haben, auch so funktioniert, wie wir das eigentlich vorgestellt haben mit der normalen Entwicklung.
Ja, mehr kann ich momentan noch nicht viel sagen.
Wir sind noch zu jung in dem Bereich.
Wir müssen noch viel Erfahrung bauen und vielleicht auch am Ende des Tages ein bisschen mehr schlauer werden, wie wir das am besten messen können.
Da sind wir alle noch in dem Prozess drin, um das sicherzustellen.
Es ist völlig klar, wenn sich natürlich Prozesse ändern, wenn sich ganze Software Development Life Cycles ändern und die Herangehensweisen, wie man Software entwickelt, dann hat das natürlich auch eine Auswirkung auf die Rolle des CTO, der all das verantwortet.
Zumindest ist das sehr stark anzunehmen.
Jetzt sehen wir seit Anfang dieses Jahres bis jetzt eine sehr große Beschleunigung dieses ganzen dieser Transformation und auch eine Disruption in diesem Bereich an vielen Stellen.
Du bist jetzt Teil davon, weil du auch AI einführst in der Organisation.
Wie verändert es gerade deine Rolle als CTO?
Tut es das denn?
Kannst du das jetzt schon sehen?
Jetzt, wenn du von Blickst von Anfang des Jahres bis jetzt?
Ja, definitiv.
Also das verändert sich definitiv, weil es ist so, die Rolle der CTO...
war das ja vorher ganz klar, es gibt dieses Team, man entwickelt die verschiedenen Features, wir müssen die Technologie bestimmen, wir müssen nicht Funktional Requirements bestimmen.
Der Prozess ist relativ klar.
Und dann kommt ein AI dazu und dann müssen wir plötzlich alles umstellen.
Das heißt, der CTO ist derjenige, der als erstes eigentlich ganz klar im Kopf ist, haben muss, okay, wie muss ich jetzt eigentlich meine Organisation befähigen, damit die Transformation uns gelingt.
Die Rolle einer CTO war vorher, wenn das vorher war, sehr viel organisatorisch oder Sitzung leiten und so weiter, jetzt geht es ein bisschen mehr in Hands-on.
Der CTO muss die AI-Transformation leiten, der muss selbst ausprobieren, der muss die der Urteil, die technischen Urteile fällen können.
Natürlich nicht bis in die Tiefe.
Natürlich braucht er seine Senior Engineering.
Aber er muss in der Lage sein, zu beurteilen, passt das jetzt, das Ganze, was auf dem Markt da ist, zu unseren Bedürfnissen in dem Unternehmen.
Da ändert sich genau darin.
Und da sehe ich mich auch total darin, meine Rolle zu verändern.
Ich muss viel mehr schauen, was passiert draußen.
sehr viel mit den Leuten reden, ich muss sehr viel selber ausprobieren, ich muss viel, viel mehr lesen.
Das ist eine ganz andere Art, eine Rolle, wie ich vor einem Jahr bekannt habe.
Das ändert sich wirklich massiv und das ist etwas, wo wahrscheinlich nicht mehr so zurückgeht, wie es vorher war.
Das kann ich mir auch vorstellen.
Also ich kann mir mehrere Wege vorstellen.
Ja, ich sehe auch den Hands-on CTO sehe ich gerade sehr viel stärker wieder auf dem Vormarsch, weil jetzt Bereiche nochmal sehr viel mehr Hands-on Expertise benötigen, weil noch so wenige, die hier die Richtung vorgeben können.
Ich weiß noch nicht so genau, wie langfristig das sein wird oder ob wir in einem Jahr oder zwei von jetzt an das CTO wieder sehr viel strategischer sein kann und das Hands-on gar nicht mehr so notwendig ist, weil sich dann schon vieles...
etabliert hat.
Das kann natürlich auch sein, das weiß ich nicht.
Interessant ist aber auch die Frage, du hast jetzt eine ganze Menge Themen beschrieben, die du mehr machst oder die du jetzt anders machen musst wie vorher.
Was musst du denn dafür sein lassen?
Oder du kannst dir nicht nochmal on top 30%, 40%, 50% mehr Effort reingeben.
Irgendwas wirst du dafür ja weniger machen müssen.
Ja, das ist eine sehr schwierige Frage.
Weil, wie ich schon gesagt habe, du musst am Anfang, bevor du überhaupt Dinge abgeben kannst, wo du weißt, dass vorher deine Verantwortung war, du musst dir bewusst sein, okay, ich muss sehr viel Erfurt investieren, um zu verstehen, die neue Welt und das andere zu sagen, alles klar, die kann ich tatsächlich anders bewerten, anders abgeben oder vielleicht existiert sie nicht mehr.
Ich bin gerade in dieser Phase zu sagen, okay, welche Art von Meeting oder welche Art von Taskbearbeitung, welche Art von Dynamik innerhalb von dem Team muss ich jetzt ändern im Zuge der AI-Transformation.
Das sind die Dinge, wo du am Anfang sehr, sehr viel Zeit und Stunden leisten musst, bevor das richtig runtergeht.
Weil alles, meiner Meinung nach, alles, was du am Anfang verpasst, weil du zu schnell abgegeben hast, kann wieder zum Boomerang werden.
Das heißt, du musst richtig klar werden, diese Transformation, was kann ich abgeben, wie du so gesagt hast.
Und ich bin gerade dabei, es gibt viele, viele so Sachen, wo ich vorhin schon gesagt habe, irgendwelche Synchronisationsmeeting A, B, C, D.
Es gibt diese Art von Meetings vielleicht nicht mehr.
Stattdessen gibt es Enforcement-Methodologie, die wir dann sozusagen das Team übergeben können.
Im Falle von AI, wo ich nicht unbedingt da sitzen muss und sage, okay, er muss das machen, das machen, sondern mithilfe von AI kann man viele, viele Dinge...
nach vorne einforsten, auch im Bereich Architektur zum Beispiel, oder?
Ja, und ich glaube, da muss man immer noch mal die Balance finden zwischen, also auf der einen Seite als CTO hast du ja auch durchaus einen unternehmerischen Blick auf Technologie und du musst ja dann balancieren zwischen der unternehmerischen Geschwindigkeit und dessen, was technische Systematik ist.
Ich nenne es mal so.
In dieser Gemengelage gibt es ja selten irgendeine perfekte Lösung, sondern meistens ist das ein Kompromiss oder eine Ja, irgendwas in diese Richtung.
Wie entscheidest du das denn?
Also wann du bewusst schnell machst und wann du bewusst kontrolliert vorgehst?
Ja, es ist so, dass die Entscheidung liegt natürlich in der Natur der Geschehen pro Tag.
Also sprich, unser Hauptbrio ist ja momentan tatsächlich diese AI-Transformation nach vorne zu bringen.
Das ist unser Hauptbrio.
Das müssen wir schaffen, weil das ist für uns entscheidend.
Das bedeutet alles andere.
muss ich runter priorisieren von meiner Arbeit her.
Beziehungsweise ich schaue, wann ich das machen kann.
Oder ich muss schauen innerhalb von Organisationen, wer kann gewisse Aufgaben tatsächlich übernehmen.
Ich denke, das ist eine am Ende der Priorisierungsfallaufgabe.
Aber am Ende des Tages ist es ja so, dass man über diese Phase vielleicht weggeht.
Daraus reduziert sich dann komplett anderer Weg, wie man die ganze Organisation innerhalb von dieser AI-Transformation eigentlich bauen soll oder beziehungsweise ausrichten soll.
Es gibt gewisse Rollen, die vorher, nennt sich Requirements Engineering, Architect und so weiter, vielleicht fließen das aneinander, weil ich vorhin gesagt habe, Spezifikation, Verifikation ist wichtiger und Coding ist immer wichtig.
Das bedeutet, Es muss so sein, dass irgendwann die Rolle, also die gewisse Aufgabe von CTO von vorher auch verteilt werden kann innerhalb vom Team.
Das wird anders sein.
Und ja, wie ich schon vorhin gesagt habe, dadurch, dass es momentan die priorisiert von uns im Unternehmen sehr wichtig ist, die AI-Transformation, da muss ich natürlich als erstes reingehen.
Da ist mein Weg.
Und natürlich gehen bei solchen Sachen auch Dinge schief.
Und das sind ja eigentlich sogar die besten Learnings, die man daraus ziehen kann, wenn Dinge nicht funktionieren im ersten Schritt, obwohl man sich das so schön auf dem Kreisband ausgedacht hat.
Was hat denn bei eurem bisherigen Ansatz nicht funktioniert oder länger gedauert, als du erwartet hattest?
Ja, das ist tatsächlich so.
Also der Workflow funktioniert sehr, sehr gut bei Greenfield Approach, wenn man das von super schön anfängt.
Von vornherein.
Wo es nicht so gut funktioniert, wo wir jetzt momentan noch dran sind am Arbeiten, ist tatsächlich das ganze Workflow auch in unserem bestehenden Applikation zu nutzen.
Insbesondere bei der Applikation, die schon lange existieren, die sogenannten Monolithen sozusagen.
Das ist viel schwieriger als gedacht.
Man muss sehr viel Kontext am Anfang ziemlich mitgeben zu der AI, damit er versteht, wie er es eigentlich machen muss.
Das reicht nicht nur die Use Case, Architekturentscheidung und so weiter.
Man muss viel, viel mehr geben.
Man muss die Datenmodelle bekannt geben.
Man muss ein gewisser Flow, Business Flow innerhalb von der Applikation sogar mitgeben, weil einige von unserer Software tatsächlich auch bedient werden kann nur von fachlichen Menschen.
Somit auch der Flow ist nicht super intuitiv, sondern das kennt nur der fachliche Mensch selber.
Das heißt, wir müssen den AI...
bekannt geben.
So funktioniert dann dieser Business-Prozess innerhalb dieser Applikation.
Und das ist unsere Hoffnung, das sieht gut aus, wenn man die verschiedenen dieser Flow tatsächlich mitgeben, inklusive die Business-Objekte, inklusive die Struktur und so weiter und so weiter, dann hat man die Hoffnung, dass es auch wirklich funktioniert.
Aber momentan funktioniert sie noch nicht.
Das ist unser Learning.
Wir müssen einfach schauen, wie man das am besten machen kann.
Und länger gedauert ist natürlich auch die organisatorischen Sachen, die Einführung in den Teams und so weiter, weil jeder muss erstmal damit beschäftigen.
Jeder ist nicht sofort da und sagt, juhu, ich habe jetzt ein neues Tool, sondern jeder beschäftigt sich damit und man bekommt auch viele Fragen zurück, man muss die beantworten und so weiter.
Kannst du dir ausmalen, wie Softwareentwicklung bei euch in den zwölf Monaten aussehen wird, wenn euer Ansatz aufgeht?
Oder ist es...
Also ist es das, was du jetzt implementiert hast?
Also ich, was ich mir als Vision, so in zwölf Monaten, dass man tatsächlich, wir als Innovative Team, hoffentlich für Applikationen, wo wir wissen, das funktioniert der Workflow sehr gut, dass wir dort sehr viel Fokus auf, wie ich vorhin gesagt habe, komplett auf die Spezifikation und Verifikation.
dass ich mit meiner Engineering nur noch darüber diskutieren muss und nicht mehr diskutiert, wie der Code aussehen muss, wie die Zeile im Code sein musste, wie die kommentiert werden musste und so weiter.
Dass wir das hinter uns haben, dass EICS-DLC diesbezüglich auch sehr, sehr gut ist.
Wir haben sehr, sehr viel daraus gelernt und verbessert, das Ganze.
Und das ist mein Ziel, hoffentlich in zwölf Monaten, dass wir nur noch über den vorderen Teil von dem Workflow und den hinteren Teil und in der Mitte ist die einfach nur Produktions mit dem AI.
Das ist absolut der Wunsch.
Ob wir das schaffen, das werden wir sehen.
Und vor allen Dingen, das ist auch wichtig zu sagen, dass wir nochmal bewusst werden, wir können nicht Modell, also AI, die ganzen kritischen Entscheidungen überlassen.
Das heißt, umso wichtiger in zwölf Monaten, dass wir wissen, was ist unser deterministischer Kern von unseren ganzen Applikationen und die darf nicht in der AI sein, sondern die ist separat.
Wichtiger Punkt.
Und bevor wir auch gleich zu den Rapid-Fire-Fragen kommen, vielleicht noch eine letzte Frage vorher an dich, Bendry.
Denn es gibt ja durchaus noch viele CTOs da draußen, die sind noch nicht so weit wie Du bist, wie ihr seid.
Was sollte der denn jetzt, die Folgen kommen immer dienstags raus, was sollte der denn am Mittwochmorgen, nachdem er sich die Folge angehört hat, was sollte ein CTO denn tun, der jetzt vielleicht noch an dem Punkt ist, wo er gerade einzelne AI-Tools nur einsetzt, was wollte der als erstes tun und daraus halt ein belastbares Engineering-System zu machen?
Was rätst du ihm?
Ich würde mal so raten, wie wir das eigentlich auch...
am Anfang unserer Journey gesehen haben.
Wir müssen aufhören, über Tools nachzudenken.
Die CDO muss aufhören, über Tools nachzudenken, muss anfangen nachzudenken, wie soll eigentlich das Software Development Lifecycle in dem Kontext von ihrem Produkt aussehen soll und wie kann AI-Natives das Ganze helfen, um das Ganze neu zu denken.
Wir müssen die Business-Probleme über prüfbare Spezifikation und Design bis zur Verifikation gegen Acceptance-Kriterien machen und nicht, okay, welches Modell nehme ich?
Ah, dieses Fable, das ist 5.1, das ist gut und so weiter, sondern nein, die komplette Workflow muss festgelegt sein.
Das ist, glaube ich, auch eine Aufgabe vom CTO, das festzulegen.
Natürlich, das muss sich entwickeln, aber man muss ja damit anfangen.
Am Ende muss man auch die unbequeme Frage stellen, und zwar, welche unserer AI-getriebenen Entscheidungen sind in Wahrheit Dinge, die wir selber entscheiden können, technisch.
Und welche von diesen Entscheidungen müssen wir anderer Gremium überlassen?
Das sind die Dinge, die eine CTO auch innerhalb von seinem Workflow definieren muss, damit das miteinander funktionieren.
Und der Rest ist für mich eine Iteration.
Schöne Schlussfrage dazu.
Aber die Rapid-Fire-Fragen oder Schlussantwort zur Schlussfrage dazu.
Aber die Rapid-Fire-Fragen stehen natürlich noch aus.
Was ist wichtiger, Bendry?
Spezifikation oder Prompt?
Spezifikation?
weil prompt ist flüchtig und die Spezifikation ist der Artefakt, welcher das Ganze trägt.
Sehr gut.
Was ist auch wichtiger, das Leistungs- oder was möchtest du eher haben, das leistungsfähigste AI-Modell oder willst du lieber das am besten kontrollierbare?
Am liebsten beides, aber wenn du so fragst, dann am Ende kontrollierbares, weil im regulären Umfeld ist Beherrschbarkeit wertvoller als die LED-Sequenz von Leistung.
Welche CTO-Aufgabe würdest du niemals an einen Agenten delegieren?
Eben, die Verantwortung und die Entscheidung, wofür wir am Ende als Menschen, als Firma gerade stehen müssen.
Die kann man auch nicht delegieren.
Man sieht es ja gerade, wir kennen ja den Fall, OpenAI hat Hugging Face gehackt aus Versehen mit seinen Agenten.
Ja, die Verantwortung liegt natürlich immer noch bei OpenAI.
Und im Endeffekt wurde hier ein Verbrechen begangen.
unbeabsichtigter Weise, aber da wird bestimmt noch der ein oder andere Lawsuit auf OpenAI drauf zukommen und vielleicht auch auf andere.
Also Verantwortung bleibt immer bei Menschen und so oder sollte es zumindest.
Welche heute verbreitete Engineering Rolle wird sich bis 2030 am stärksten verändern?
Wie wir auch schon die ganze Zeit besprochen haben, also der klassische Implementierer oder Coder wird sich umgekehrt verändern, also vom Code-Produzenten.
bis zur Spezifikation, Architekten und Review.
Da wird es sich in diese Richtung verändern.
Was ist gefährlicher?
Was denkst du?
Zu langsame AI-Adoption oder zu schnelle AI-Adoption mit vielleicht ohne oder zu wenigen Leitplanken?
Das ist eine gemeine Frage, aber ich würde mal sagen, zu schnell ohne Leitplanken, weil zu schnell kostet natürlich Vorsprung, aber schnell...
Und eine Leitplanken kostet Vertrauen.
Und normalerweise, wenn Vertrauen weggeht, bekommt man sie nicht so einfach wieder zurück.
Ich glaube, du musst diese Antwort auch so geben, weil du aus dem regulierten Umfeld kommst.
Ich würde tatsächlich sogar eher sagen, ich würde die langsame AI-Adoption sogar als gefährlicher betrachten.
Also im Startup-ish Umfeld ist dann eher move fast and break things.
dann macht man auch mal Dinge kaputt, aber lieber zu schnell als zu langsam.
Aber ich verstehe, dass du natürlich mit einer anderen Perspektive da rangehst.
Die Antworten sind beide richtig oder wahr oder wie auch immer.
Ich muss ja wählen.
Stimmt, ich zwinge dich ja dazu zu wählen.
Wendry, wir sind am Ende der heutigen Folge.
Es hat mir sehr viel Spaß gemacht, mit dir über eure AI-Adoption zu sprechen, wie du die AI-Transformation bei Innovitech eingeführt hast, wie du sie weiter vorantreibst, was du auch...
was das mit deiner Rolle gemacht hat.
Und du hast sehr viele, sehr gute Dinge ins richtige Licht gerückt.
Und ich glaube, man kann hier nochmal sehr viel Value mitnehmen dafür, wenn man jetzt gerade an einer Stelle steht, vor der du vor ein paar Monaten auch gestanden bist, als du dir diese Frage gestellt hast oder auch diese Herausforderung von der Businessseite bekommen hast, hier Dinge maßgeblich voranzutreiben.
Ich hoffe, dass wir das Gespräch dann bei zu gegebener Zeit nochmal fortsetzen können, weil ich glaube, diese Entwicklung wird sich ja auch noch fortsetzen.
Und da bin ich sehr gespannt, wo du stehst oder wo ihr steht.
Und dann kommst du gerne nochmal zu einem weiteren Gespräch zu mir in dem Podcast.
Hey Philipp, vielen Dank für die Einladung, für das Gespräch heute.
Es hat mir Spaß gemacht.
Natürlich komme ich gerne wieder zurück auf die Einladung.
Sehr schön.
Danke dir.
Mach's gut.
Ciao, ciao.
Danke dir.
Ciao.