# Agentic AI: CTO Strategy for SaaS Survival

**Podcast:** Becoming CTO Secrets
**Published:** 2026-05-19

## Transcript

Hallo und herzlich willkommen zu Becoming CTO Secrets, deinem Podcast für die harte Realität der CTO-Rolle zwischen Tech, Team und Business.
Ich bin Philipp Deutscher, externer CTO, CTO-Coach und Gründer der Becoming CTO-Community.
Wie ihr alle wisst, Agentic AI ist gerade eines der meist diskutierten Themen im Tech-Umfeld.
Ich glaube, täglich passiert da irgendwas Neues, aber nur wenige Teams setzen es wirklich konsequent um in einem echten Produkt.
Mein heutiger Gast, haben wir auch schon mal hier im Podcast gesehen, Michael Reimann, der CTO von StarMate, einem Produkt, CRM und E-Mail Marketing.
Ja, komischer Satz gerade.
Anyways, aber ich glaube, er beschreibt es im Grundsatz ganz gut, was StarMate macht.
Und er hat genau das getan, nämlich in einer Phase, in der andere Teams eher auf Stabilität setzen würden, kurz vor dem Launch.
sind sie auf Agentic.ai umgestiegen.
Und darüber wollen wir heute sprechen.
Wir sprechen darüber, was sich technisch, organisatorisch und strategisch dadurch verändert hat und welche Entscheidungen CTOs jetzt treffen müssen.
Michael, herzlich willkommen.
Ja, danke schön für die Einladung, Philipp.
Gerne.
Und steigen wir doch direkt in das Thema ein.
Agentic.ai in aller Munde.
Ihr wart doch vor geraumer Zeit.
Du sagtest, ihr wart vier Wochen vor Launch und auf einmal...
Hat sich was für euch verändert und ihr seid ein Risiko eingegangen, dass vielleicht nicht jeder so eingehen würde?
Kannst du uns da mal mitnehmen?
In welcher Phase wart ihr wirklich und was habt ihr dann gemacht?
Ja, sehr gerne.
Das System lief soweit, war zu 85 Prozent fertiggestellt.
Und so ein bisschen haben wir schon gespürt, das wird eng und die 100 werden wir wahrscheinlich nicht ganz auf den Termin schaffen, den wir uns vorgenommen hatten.
Es wird wahrscheinlich eher so auf die 97 Prozent hinauslaufen.
Und nach einem Wochenende kam einer der Lead-Entwickler auf uns zu und sagte, Mensch, ich habe da was Neues und hat mir das gezeigt.
Und dann war sofort klar, okay, das, was wir hier gerade sehen, das ist brachial.
Das, was er ums Eck gebracht hat, war eben entwickeln mit Authentic.ai.
Er hatte da über das Wochenende mal kurz den Arbeitsstand, naja, zu 50 Prozent.
hergestellt, der bis dahin klassisch entwickelt worden ist.
Und dann war uns klar, okay, da müssen wir jetzt was tun, da müssen wir darauf reagieren.
Es war ein Schock, der im Team entstanden ist, weil das natürlich die Auswirkungen, die hat sofort jeder verstanden.
Und wir haben dann im Team gemeinsam entschieden, dass wir das Thema erst mal weiterverfolgen und die Möglichkeiten und auch die Grenzen von Agenda ausloten wollen für uns.
für unseren Zweck, für die Produktentwicklung.
Und dann haben wir das für einen begrenzten Zeitraum weiter genutzt.
Also wir haben gesagt, okay, wenn das jetzt so funktioniert, dann nutzen wir jetzt die Zeit, um das Produkt auf den Punkt zu bringen, den wir haben wollen und nutzen dafür Agentec.
Wie viel Risiko war das dann tatsächlich für euch?
Also viele würden wahrscheinlich sagen, naja, wenn wir bei...
95, 96, 97 Prozent rauskommen für den Launch, das ist good enough.
Das ist wahrscheinlich sogar mehr, als viele andere erreichen in dem Zeitraum.
Trotzdem klingt es ja nach einem Risiko.
Selbst wenn im ersten Moment das sehr ansprechend aussieht, was da passieren kann, ist es ja doch ein größerer, disruptiver Eingriff.
Absolut, ja.
Also das Frontend wurde am Ende des Prozesses dann zu 100 Prozent getauscht.
Im Backend gab es auch gravierende.
also zu einem erheblichen Anteil.
Und das Risiko war eigentlich, dass es nicht funktioniert für uns.
Also sprich, dass wir nach einigen Wochen Entwicklungsarbeit wieder an dem Stand angekommen waren, den wir dann gehabt, den wir zu dem Zeitpunkt hatten, zu dem wir entschieden haben, dass wir jetzt erstmal auf Authentic AI umsetzen.
Und damit hätten wir uns für Time-Line gerissen.
Das war insofern nicht ganz so dramatisch, als dass wir die Rückendeckung der Geschäftsführung des CEOs auch hatten.
Insofern konnten wir da einigermaßen entspannt unterwegs sein.
Aber wir hatten natürlich auch nach oben zur Gesellschaft der Ebene hin Termine kommuniziert.
Und letztlich war da das größte Risiko, dass wir einfach dann dastehen würden nach einigen Wochen Entwicklungsarbeit in der Phase, in der wir eigentlich auf das Release hingearbeitet haben und am Releasetag dann.
mehr oder weniger blank mit nur dem Ergebnis, das wir bei 85 Prozent hatten, dann dastehen würden.
Und das war uns nicht ausreichend genug, aber es war auch nicht so riskant, dass wir gesagt hätten, okay, wir lassen das so stehen und verfolgen den klassischen Weg, sondern uns war das Potenzial von Argentic eigentlich voll bewusst mit dem ersten Moment, in dem wir es gesehen haben, was da möglich ist.
Wir haben gesagt, okay, jetzt auch nur einen Tag klassisch weiterzumachen.
würde für uns im Long Run bedeuten, dass wir einfach Geschwindigkeit, die wir hätten, als Potenzial nicht nutzen.
Und dann war uns der Sankt Kostfeldersee auch völlig im Klaren, da waren wir uns völlig bewusst über den und haben dann entschieden, oder dann habe ich eben entschieden, dass wir das jetzt aktiv auf die Schiene bringen, mit dem Risiko nicht voll.
termintreu liefern zu können.
Aber es gab einen sehr guten Grund dafür.
Trotzdem eine mutige Entscheidung auch für dich als CTO.
Wie sah das denn?
Du hattest, glaube ich, geschrieben auch im Vorfeld, dass das vor acht Monaten schon war.
Ich glaube, bei den meisten ist der Startschutz für Argentic AI vielleicht so Anfang des Jahres kann man das so groß terminieren.
Bei den meisten anderen Unternehmen mit den Entwicklungen, die es dann auch Richtung Cloud Code und sowas geht, mit den Themen, mit denen man sich da...
oder die Entwicklungen, die dann nochmal rasant Fahrt aufgenommen haben.
Was war das konkret, was ihr vor acht Monaten schon gebaut hattet an Infrastruktur, was dich davon überzeugt hat, das ist jetzt der richtige Weg?
Kannst du das ein bisschen genauer beschreiben, was ihr da schon hattet?
Also es war ja wahrscheinlich mehr als reine Augmentierung von Engineers mit einem Cursor oder einem Windsurf, sondern es war wahrscheinlich ja doch schon ein bisschen mehr.
Ja, wir hatten, also...
Genutzt als Tool haben wir damals Warp.
Das spielt aber gar keine große Rolle, welches Tool man da konkret verwendet.
Am Ende des Tages ist es ja immer die Frage, was für eine Automatisierung hast du hinten dran?
Welche Models verwendest du am Ende des Tages?
Und tatsächlich waren wir bis dahin eher wirklich klassisch unterwegs.
Also unsere Entwickler, ja, die haben schon mal wie mit Gemini oder ChatGPT oder auch mit einem Cloud gearbeitet und haben da von Handabfragen reingeworfen oder Prompts reingeworfen und haben das dann entsprechend in Code generieren lassen, rausgenommen.
Und der Breakthrough war eigentlich, dass eben das agentische Vorgehen dann in dem Fall auf den verschiedenen Modellen, die da zum Einsatz kamen, unter anderem auch.
der damit verwendet wurde.
Ich weiß gar nicht, was wir noch alles hatten.
Das dreht sich alles so schnell.
Man vergisst das ja auch wieder.
Und diese Erkenntnis eigentlich zu sagen, okay, wir haben hier die Geschwindigkeit, das war der Punkt, an dem wir dann vorwärts gegangen sind.
Gab es dann trotzdem noch einen Punkt, an dem du dachtest, das fliegt uns jetzt komplett um die Ohren?
Den gab es.
Der Pareto ist ja auch hier mit an Bord, also sprich das 80-20-Prinzip.
Und das hatte ich so nicht auf dem Schirm, natürlich nicht.
Wenn man so am Anfang die Wunderkiste sieht und sieht, okay, ich kann da innerhalb von, ich weiß es nicht, wenigen Arbeitstagen ganz viel gemacht bekommen, dann glaubt man ja für den ersten Moment auch, dass so klassische Prinzipien dann über Bord geworfen werden können.
Und das ist nicht so.
der ist an Bord, der Pareto, und den muss man auf dem Zettel haben.
Du brauchst hinten raus immer noch diese 80 Prozent deiner Entwicklungszeit für die letzten 20 Prozent der Leistung.
Und als wir bei diesen letzten 20 Prozent angekommen sind, da hatte ich dann schon so, ja, immer wieder Situationen, in denen ich dachte, okay, das fliegt uns jetzt so um die Ohren, das kriegen wir mit diesen neuen Mitteln überhaupt nicht mehr in den Griff.
Wir hatten Rekursionen, wir hatten...
Regressions und all diese Themen, die man so kennt, die hatten wir dann auch und denen mussten wir dann begegnen und dann bin ich eben hergegangen und habe wieder das Team fokussiert, habe geschaut, dass wir wieder die klassischen Dinge, die man eben so tun muss, um diese Themen in den Griff zu bekommen, dass wir die auch wieder anmelden.
Wir waren ein bisschen nachlässig geworden im Branching, wir waren Ja, auch was das QS anbelangt, wir hatten die Dinge einmal durchgetestet und hatten sie dann liegen lassen, um dann festzustellen bei Friendly User Tests, dass Dinge, die eigentlich als getestet und stabil verabschiedet waren, dass die eben dann nicht mehr gelaufen sind und solche Effekte.
Und dann haben wir also eben das Branching wieder konsequent angewendet.
Wir haben wieder das QS auch auf bereits fertiggestellte Produktteile angewendet.
so dass wir immer wieder sicher gehen konnten, dass wir alles getestet haben, auch das Zusammenspiel, nicht nur Unit-Tests und haben auf diese Art und Weise dann das so nach und nach in den Griff wieder bekommen und haben natürlich auch daraus gelernt, an welchen Stellen die Themen dann entstehen, auch beim Prompting.
Also das waren dann so die Mikroerfahrungen, die jeder in der Entwicklung dann auch gelernt hat.
Wie nimmst du denn oder wie hast du denn Entwickler?
mitnehmen müssen, gerade in der ersten Phase.
Du hast gesagt, ein Entwickler ist sehr proaktiv auf dich zugekommen und hat dir gezeigt, was er damit jetzt schon machen kann.
Das sind wahrscheinlich mehr wie Einentwickler in der Company und vielleicht ist auch nicht jeder genauso progressiv oder genauso begeistert, was den Einsatz von Agentic AI oder LLMs angeht.
Gab es kritische Stimmen im Unternehmen?
Und wie hast du die mitgenommen?
Kritisch wäre ein zu hartes Wort.
Es gab vorsichtige Stimmen.
Also die Menschen, die gesagt haben, ja, Moment mal, da müssen wir aufpassen, weil das hat Sicherheitsaspekte, die wir da berücksichtigen müssen.
Und so ein Hinweis ist natürlich völlig zutreffend.
Und der erste Impuls oder das wichtigste Element in der ganzen Umstellung war eigentlich, dass der Impuls aus dem Team rauskam.
Also wenn ich das von oben her...
dem Team aufgedrückt hätte, dann hätte das nicht funktioniert.
Das ist wie immer im Change.
Wenn es aus dem Team herauskommt, dann ist da eine gewisse Motivation da.
Wir haben das unheimliche Glück auch, dass wir eben als Unternehmen, als ganzes Unternehmen, das jetzt gerade zwei Jahre alt wurde, dass wir das Unternehmen als solches schon auf modernen Prinzipien aufgebaut haben, von der ganzen Art und Weise her, wie wir arbeiten.
Es gibt ein methodisches Framework, auf dem das ganze Unternehmen aufgebaut ist.
Das hat nichts mit KI zu tun, das würde jetzt auch zu weit gehen.
Aber dieses Arbeiten mit Methoden, dieses Arbeiten entlang von Prinzipien, dieses Arbeiten mit Werten, mit Core Values, das ist das ganze Team schon gewöhnt, weil wir das von Anfang an dem Unternehmen auf...
als Stempel aufgedrückt haben.
Und dieses, wir entwickeln jetzt mit einer KI, mit der wir methodisch vorwärts kommen, mit Agentic KI, mit der wir methodisch vorwärts kommen und wir haben dazu Prinzipien, wir haben dazu Regeln, wir haben dazu Werte, also wir haben sehr schnell dann auch mit dem Team zusammen das Vorgehen entwickelt, als Leitlinie, als Leitplanken.
Das hat alles dazu geführt, dass dann das Team auch das sehr schnell akzeptiert hat.
Plus, die Menschen sind es ohnehin gewohnt, progressiv zu arbeiten aufgrund der ganzen Architektur, die wir im Unternehmen haben.
Und damit war das relativ gut möglich, die Mitarbeitenden mitzunehmen, die Entwicklerinnen mitzunehmen, aber auch zum Beispiel die Kolleginnen im QS mitzunehmen und auch bei ihr jetzt keine Ängste hervorzurufen, sondern sie konstruktiv abzuholen, ihr zu sagen, du pass mal auf.
Wir brauchen dich in Zukunft.
Deine Rolle ist jetzt vielleicht nicht mehr die, dass du von Hand irgendwelche Dinge anklickst irgendwann in Zukunft, sondern dann wird deine Rolle mehr so aussehen, dass du die Agentenorchestrierst, dass du die Agentenorchestrierst, dass du eben dafür zuständig bist, dass das, was die herausfinden, dass das stimmt und dass das auch zuverlässig ist.
Und so haben wir eigentlich für jede Rolle dann auch durchgesprochen.
wie die Leute sich in Zukunft das vorstellen können.
Wir sind aber immer noch dabei.
Also das ganze Thema Personalentwicklung hat vor diesem Hintergrund bei uns gerade einen hohen Stellenwert.
Und wir sind dabei, die Rollenbeschreibungen auch in die Zukunft auszurichten.
Und aber auch die Personalplanung.
Also es geht so weit, dass wir eben auch Personalentscheidungen, die wir eigentlich letztes Jahr noch hätten treffen wollen.
Also wir haben irgendwann im Herbst eben die Umstellung gemacht.
Und da war durchaus noch die Überlegung, wollen wir uns jetzt zu Anfang dieses Jahres noch jemanden leisten in der Entwicklung?
Also Stellen ausschreiben.
Und das haben wir dann erst mal zurückgestellt.
Wir haben gesagt, wir können im Moment gar nicht einschätzen, wohin die Reise überhaupt geht für uns.
Wir wussten nicht, wen wir brauchen, was diese Person und Fähigkeiten haben muss.
Und haben dann deshalb die Entscheidung erst mal zurückgestellt, um sie jetzt wieder zu treffen und tatsächlich etwas verändert auszuschreiben.
Okay, das ist ein interessantes Beispiel.
Das heißt, ihr habt dann gesehen, ihr braucht diese Rolle vielleicht erstmal nicht.
Ihr kriegt auch so genug PS auf die Straße.
Kannst du das nochmal konkretisieren?
Wie hätte die Rolle vorher ausgesehen und wie sieht sie jetzt aus?
Ist das ein ganz anderes Rollenprofil, was ihr jetzt sucht oder ist es nur leicht angepasst?
Sucht ihr immer noch den Senior Engineer, aber mit einem leicht anderen Fokus oder ist es jetzt auf einmal eine ganz andere Rolle, die ihr sucht?
Also wir suchen jemanden oder wir suchen jetzt Menschen.
Die Erfahrungen haben wir im Umgang mit KI, die Erfahrungen haben wir auch mit Agentic KI, um da eben nicht ganz von vorne anfangen zu müssen.
Was uns nicht mehr so wichtig ist wie früher, ist die Fähigkeit und die Leidenschaft, tief in den Code abzutauchen und die letzten Quäntchen aus dem Code rauszuholen.
Es reicht uns, wenn ein grundsätzliches Codeverständnis da ist.
Wir haben erfahrene Kolleginnen und Kollegen in der Entwicklung.
Was uns wichtiger ist, ist im Moment, dass jemand in der Lage ist, KI gesamtheitlich zu orchestrieren, also sprich die Agenten so zu befähigen, dass die selbstständig rennen können.
Und das ist jetzt was ganz anderes, als ich mache mir über die Code-Architektur im kleinen Bereich, also über die Mikro-Architektur-Gedanken.
Ich muss Architektur als Ganzes verstehen, ich muss die Systeme verstehen, die da zusammenspielen.
einen Überblick haben über die Dinge, die da passieren, über die Prozesse, die in den Systemen ablaufen.
Und das sind andere Fähigkeiten, als ich bin auf Schleifenebene oder sonst wo im Code unterwegs.
Wenn man bei euch jetzt reinschaut, was ist denn da tatsächlich agentik und was ist es vielleicht noch nicht?
Du hast ja gerade eben das Beispiel der Quality Assurance oder Qualitätssicherung angemerkt, die sich vielleicht mehr als jemand verstehen muss zukünftig, der Agents orchestriert, die Qualitätssicherung betreiben.
An welchen Stellen ist das schon so, dass ihr hier wirklich richtig agentik unterwegs seid?
An welcher Stelle ist es doch sehr, sehr, sehr viel Human in the Loop oder sehr viel Human, der noch die Dinge aktiv vorantreibt?
Also das ist ein sehr wichtiges Stichwort, das du da gerade gesagt hast.
Der Human in the Loop ist für uns immer mindestens am Ende der Prozesse relevant.
den braucht es immer am Ende des Prozesses.
Auch weil eines unserer Leitbilder, die wir haben, in Richtung der Kundenkommunikation ist, dass wir menschlich sind, dass wir auf menschlicher Ebene miteinander kommunizieren.
Das heißt, alles, was wir machen, alles, was wir als Ergebnis haben, da muss immer auch ein Mensch am Ende drüber schauen und letztlich auch dahinterstehen können.
Ansonsten ist es so, in der Entwicklung haben wir umgestellt, da ganz massiv.
Also die Entwicklung sieht heute ganz, ganz anders aus als vor acht Monaten.
Vor acht Monaten haben wir klassisch entwickelt, nur ein bisschen KI.
Heute entwickeln wir Argentic mit, na ja, ab und zu vielleicht mal noch einem händischen Eingriff.
Aber es ist eigentlich schon ziemlich wenig geworden, also fast bei Null.
Die QS ist dabei.
immer mehr Agentik aufzunehmen.
Also da werden die ganzen Testszenarien, die werden immer mehr automatisiert, sodass wir da auch auf einem sehr, sehr guten Weg sind.
Und dann ist es so, dass wir nicht nur SaaS-Anbieter sind, im Sinne von wir produzieren ein System und stellen das bereit, sondern wir stellen dazu auch, dass ein B2B-System ist, eben Consulting-Dienstleistungen bereit.
Das heißt, man kann bei uns das Onboarding buchen, sich beraten lassen im Hinblick auf, wie muss eine technische Konfiguration aussehen oder ich habe ein Wunschzielbild, auf das ich hinarbeiten möchte, einen Wunschprozess, den ich einrichten möchte und kann sich dahingehend von uns beraten lassen.
Aber wir gehen auch in das Thema Kommunikationsberatung ein.
Wir haben ein Kommunikationstool, das wir auf dem Markt anbieten und wir bieten auch die Beratung für die Inhalte an.
Und das sind also Dienstleistungen, die wir an der Stelle erbringen, die natürlich sehr, sehr manuell getrieben sind.
Also die werden von Menschen erledigt.
Aber dieser ganze Prozess, Auftragsanfrage, Angebotserstellung, das ist ein Prozess, der lief klassisch ab.
Und da sind wir gerade dabei, den auch umzubauen und den immer mehr zu automatisieren, sodass wir an der Stelle für den rein formalen Verwaltungsakt eines Auftrags nichts mehr tun müssen, sondern dass die gesamte Organisation, die damit verbunden ist, dass die über Argentic automatisiert ist.
Das spüren wir jetzt schon.
Wir sind da mitten in der Umstellung, haben einiges schon erreicht, aber haben auch noch ein bisschen was vor uns.
Und die Schritte, die wir schon automatisiert haben, da merken wir schon deutlich, dass wir da Geschwindigkeit drauf bekommen, dass wir da Qualität drauf bekommen im Sinne von Fehlervermeidung und dann eben auch valide Informationsweiterreichung im Team.
sodass dann am Ende der Kette auch das ankommt, was am Anfang der Kette an Informationen reinging.
Und das ist sehr, sehr wertvoll, weil wir dadurch nicht nur die Qualität der Arbeiten steigern, sondern weil wir da eben auch den Informationsfluss erhöhen und die Transparenz auch bei uns, also in der Geschäftsleitung, eben erhöhen im Hinblick auf, welche Kapazitäten haben wir, was steht denn an.
etc.
Da bekommt man jetzt in Echtzeitberichte, das war früher nicht immer so.
Ja, das glaube ich dir.
Darf ich mir das trotzdem vorstellen?
Wie war der Grundgedanke beim Aufbau eurer Agentic AI Prozesse?
War das dann ein Mensch, er stellt immer noch ein Ticket, er ist für die Requirements und die Akzeptanzkriterien und die gesamte Beschreibung des Tickets und dessen, was gemacht werden soll, verantwortlich, dann landet das in einem Backlog und wenn es einen bestimmten Status hat, Dann fängt ein erster Agent an loszulaufen und beginnt mit der Implementierung.
Dann übergibt er das an einen zweiten Agent, der dann quasi Tests schreibt und die Qualitätssicherung macht.
Oder habt ihr das dann gleich so versucht aufzusetzen?
Das ist der erste Teil der Frage.
Und der zweite wäre dann dazu, was ist euch denn da als erstes auf die Füße gefallen, als ihr das versucht habt so umzusetzen, wenn das denn so ist?
Also die Grundidee ist, den kompletten First-Level-Support eben agentik zu machen.
Das heißt, kleine Fehler, also Kundenanfragen, die klar benennbar sind, die repetitiv sind, also wieder ruhend sind im Sinne von, das haben Kunden immer wieder das Thema, dass wir das automatisiert gelöst bekommen.
Tatsächlich stellt sich da eben heraus, dass größte Stolperfalle, also dieser ganze administrative Prozess, der ist kein Problem.
Ticket-Label, Ticket-Clustern und so weiter.
Das ist überhaupt kein Problem.
Das geht gut.
Der größte Stolperstein in der Kette ist die Umsetzung dann tatsächlich, weil wir zwar ein SaaS-Standardprodukt haben, aber dann ist es eben doch so, dass wir einen relativ hohen Konfigurationsanteil haben pro Kunde und den muss das System erstmal beherrschen.
Also das zu verarbeiten ist etwas, Da reicht es nicht einfach das Basissetup des Systems dem Agenten zu füttern, sondern da musst du ein bisschen mehr Kontextwissen haben.
Und das ist etwas, was noch ongoing ist, das zu vermitteln.
Das haben wir uns ein bisschen einfacher vorgestellt.
Wie gehst du mit dem Problem um, dass ein großer Unterschied zwischen einem Seniorentwickler heute und einer sehr guten...
oder einem sehr guten Agent ist meistens ja nicht, dass der Senior-Entwickler immer noch besser entwickeln kann.
Das kann er tatsächlich nicht.
Aber er hat meistens mehr Kontext, den richtigen Kontext.
Er hat mehr implizites Wissen.
Dinge, über die niemand spricht, aber die sehr wichtig sind für das, was die AI am Ende des Tages dann doch tun soll.
Und das ist auch in vielen Unternehmen der Grund, warum der Agent erstmal losläuft und er baut etwas und danach stellt man fest, das wollte ich ja gar nicht.
Man hat genau diesen Kontext im Endeffekt nicht hinzugefügt.
Wie geht ihr mit dem Thema Kontext um?
Wie dokumentiert ihr das?
Wie stellt ihr das den Agents zur Verfügung?
Sehr konsequent.
Also sobald wir darauf stoßen, dass es einen Kontext-Gap gibt, wird das in Markdowns entsprechend notiert und dem Agent zur Verfügung gestellt, sodass wir dann an der Stelle sicherstellen, dass wir alles, was wir tun können, um den Agent zu befähigen, das Ergebnis zu erreichen, das wir erwarten.
dass wir das auch tun.
Wir haben ein Ziel, da komme ich wieder auf das methodische Framework, das wir eingeführt haben bei der Unternehmensgründung.
Wir haben ein Ziel, das wir damals schon vorgegeben haben, dass er in zehn Jahren, also jetzt noch acht Jahre, hinarbeitet und uns ist allen völlig klar, dass wir das nur erreichen können, wenn wir es schlau machen, wenn wir es effizient machen, wenn wir gut vorgehen.
schlau machen, dieses effizient vorgehen.
Wir wussten vor zwei Jahren bei der Gründung noch nicht genau, welches Werkzeug uns da helfen wird und wie wir da wirklich dieses Ziel erreichen können.
Aber heute wissen wir, dass Argentic ein ganz, ganz wesentlicher Baustein dafür sein wird.
Und indem wir das so auch gesagt haben und uns gegenseitig das auch ausgesprochen haben.
Also das war nicht nur etwas, was ich als CTO gesagt habe, sondern das kam auch aus dem Team zurück als Feedback, quasi zeitgleich im gleichen Meeting.
Ist das etwas, was im Team auch angekommen ist und bewusst ist und verankert ist und was dort auch als wichtiger Faktor für den Unternehmenserfolg erkannt wurde?
Und deshalb ist auch sichergestellt, dass wir im Team da die Akzeptanz dafür haben.
Sicherlich bei den einen mehr, bei den anderen ein bisschen weniger, aber im großen Durchschnitt ist es da.
Welche Use Cases haben sich dabei als echte Game Changer herausgestellt?
Also das Vorgehen in der Entwicklung ist der größte Game Changer.
Da haben wir die größte Geschwindigkeit.
Wenn ich heute überlege, wie wir vorgehen, wir haben jüngst erst eine sinnvolle Produktergänzung gebaut, die uns die Kunden schon vor Jahren sich gewünscht hatten.
Wenn ich jetzt so von Jahren spreche und dann zwei Jahre, wir sind ja eigentlich aus einem großen Softwareunternehmen ausgegründet worden.
Die Produktlinie gibt es schon seit 20 Jahren.
Und vor diesem Kontext eben ist das auch zu verstehen, wenn ich sage, vor Jahren haben sich die Kunden das gewünscht.
Dann haben wir das damals immer abgelehnt, weil wir gesagt haben, wir haben einen Produktfokus.
Das ist die eine Seite der Medaille und die zweite Seite der Medaille, die wir nicht so laut gesagt haben, ist, Leute, wir haben gar nicht so viel Kapazität, um das zu entwickeln.
Uns war immer klar, es wäre eine sinnvolle Ergänzung, aber es war eben doch nicht ganz im Fokus und wir hatten auch nicht die Kapazität, um es zu entwickeln.
Heute gehen wir jetzt her, haben die Möglichkeit über Agentic KI entsprechend die Dinge, die wir da brauchen, zu entwickeln und entwickeln die auch.
Kannst du den Erfolg, den ihr jetzt mit Agentic AI habt, kannst du den quantifizieren, qualifizieren?
Also im Sinne von, wie sich eure, das schöne Wort, Delivery Capabilities erhöht haben.
Also habt ihr jetzt mehr Velocity, kannst du das in irgendeiner Art und Weise messen, den Durchsatz an Tickets, an so weiter, oder ist es am Ende des Tages, Lines of Code, keine Ahnung, wie misst du das?
Ja, Lines of Codes werden in dem Kontext so ein bisschen leider relevant.
Vielleicht ist es die Velocity, die da als guter Messwert gibt.
Also wir intern verwenden die Velocity.
Wir wissen, Dinge, die heute oder die früher in zwei Monaten gegangen wären, die zwei Monate gebraucht hätten, die gehen heute in zwei Tagen.
Das ist...
Das ist eigentlich die Erkenntnis, die wir haben und den Geschwindigkeitszuwachs, den wir haben.
Habt ihr Stack-Entscheidungen dann auch getroffen, die anders ausgefallen wären, wie wenn ihr sie selbst getroffen hättet?
Also ich weiß nicht mehr genau, wir haben uns ja im letzten Jahr schon mal unterhalten, ich weiß nicht mehr genau, was euer Stack war und ob wir das so konkretisiert haben, aber ist davon jetzt noch...
die gleiche Technologie übrig geblieben oder gab es dann auch in dem Zusammenhang andere Programmiersprachen, die verwendet wurden, andere Stack-Bestandteile, die vorher gar nicht in Betracht gezogen wurden, aber das kam halt durch Agentic AI?
Ja, zum Teil, aber der Großteil ist gleich geblieben.
Also wir haben einen Stack, der besteht in der Datenbank aus Postgre und dann im Backend aus Java.
Im Frontend hatten wir damals entschieden, als wir Also damals meint, als wir begonnen haben, das neue Produkt, die neue Produktlinie zu schreiben, hatten wir entschieden, auf keine Frameworks zu setzen, um die volle Kontrolle zu haben.
Das hat sich geändert mit der Einführung von Agentic.
Denn da haben wir jetzt den Frontend React im Einsatz.
Im Backend und in der Datenbank hat sich nichts geändert.
Hat quasi der Agent empfohlen, React zu nehmen und euch eine gute Begründung geliefert?
Ja.
Okay.
Okay.
Genau.
Was wäre die Alternative gewesen?
Was hättet ihr gemacht?
Plain JavaScript?
Ja, genau.
Wir waren eigentlich mit Vanilla unterwegs, also plain JavaScript unterwegs.
Und die Empfehlung war dann, nimm React, weil damit geht es doch deutlich schneller und einfacher und besser.
Okay, verstanden.
Was machen denn jetzt die Entwickler?
Wie arbeiten die jetzt anders als noch vor acht Monaten?
Gerade wenn sie jetzt nicht mehr den ganzen Tag selbst...
Code schreiben.
Ein Agent ist vielleicht sehr schnell zu Ende mit der Implementierung etwas, wofür ein Mensch vielleicht mehrere Tage dafür gebraucht hätte in der Summe.
Wie darf ich mir dann die Arbeit des Entwicklers in der Zwischenzeit vorstellen?
Er wartet wahrscheinlich auf den Output des Agents.
Was macht er in der Zwischenzeit und wie definiert sich dann seine Arbeit?
Ja, also die Haupttätigkeit der Entwickler ist Orchesterierung von den Agenten.
Das heißt, Die lassen den Agenten laufen, schauen sich das Ergebnis an.
In der Zwischenzeit kommt es darauf an, wie lang die Laufzeiten sind.
In der Regel haben wir nur ein paar Minuten Laufzeit.
Dann schaut man eben, okay, kann man zwei parallel laufen lassen, macht das Sinn.
Oder man ist noch damit beschäftigt, sich das Ergebnis des vorherigen Laufs anzuschauen, um nochmal Verbesserungen vornehmen zu können.
Die Tätigkeit der Entwickler bei uns hat sich tatsächlich eben mehr zu intelligenten hin entwickelt.
Also einfach zu schauen, passt das Ergebnis mit meinen Anforderungen überein?
Ist es so das, was eigentlich gewünscht ist?
Und dann kommt noch dazu, wir haben in der Entwicklung das Vorgehen als solches auch geändert.
Also das meint nicht nur die Erstellung von Code, sondern auch die Organisation des Projektes.
Wir haben uns von Jira verabschiedet.
Wir haben eine eigene Plattform am Laufen, die nahtlos in das Entwicklung mit Argentic eingreift und da auch die Befähigung herstellt.
Wir haben eine eigene Plattform entwickelt dafür, als Randprodukt, als Nebenprodukt.
Das wird man bei Atlassian jetzt nicht gerne hören, dass ihr euch von Jira verabschiedet habt.
Aber ich kann mir gut vorstellen, dass das einige andere auch so tun werden und sich immer mehr davon verabschieden.
Das heißt, ihr habt eine eigene Lösung gebaut, um jetzt euer Backlog und euer Ticketing zu nutzen und um das besser in euren neuen Agentik, AI-Stack zu integrieren?
Ja, richtig, genau.
Okay, sehr gut.
Ja, tatsächlich habe ich sowas ähnliches auch gemacht.
Also gerade vor dem Hintergrund, die Frage für eigene Projekte und die willst du ja auch irgendwie, willst ein eigenes Backlog halt dafür bauen und so.
Und da ist halt auch die Frage, setzt du auf etwas auf, was es schon am Markt gibt oder ist es dann an vielen Stellen einfacher, sich was Eigenes zu bauen, weil es dann doch eher den eigenen Bedarfen und dem eigenen Use Case und den eigenen Prozessen dann entspricht.
Aber es ist interessant zu sehen, dass ihr das ähnlich gemacht habt.
Und wie lange habt ihr dann dafür gebraucht?
Also habt ihr dafür dann...
auch nochmal ein paar Wochen gebraucht, um sowas zu bauen oder war das dann innerhalb von ein, zwei Tagen dann quasi so eine Art MVP am Start und damit seid ihr einfach losgerannt?
Ja, letzteres.
Also innerhalb von, ich glaube, einer Woche stand der MVP.
Wir haben dafür auch einen Werkstudenten, der bis dahin eben klassisch mitentwickelt hatte, kleine Aufgaben übernommen hatte.
Den haben wir komplett für das Thema dann verwendet und der ist da dann auch voll aufgegangen.
Also das ist auch so ein Beispiel, wie man Menschen dann wertvoll weiterentwickeln kann.
Wir haben den Asphaltstudenten vor zwei Jahren bei der Unternehmensgründung direkt an Bord geholt.
Der hat sich im Bereich QS bewegt, hat aber auch entwickelt und war da somit in beiden Spielfeldern unterwegs.
Hat aber immer gesagt, er fühlt sich eigentlich mit der wirklichen puren Entwicklung gar nicht so wohl.
Er will mehr in die Richtung QS oder auch in die Richtung also sprich auch mehr mit Kunden, so die Schnittstelle zwischen Kunden und Technik besetzen.
Und so hatten wir ihn dann eigentlich auch schon so ein bisschen eingejustiert.
Und es war damals schon klar, wenn wir gut miteinander können, wenn das für alle funktioniert, dann übernehmen wir ihn nach seinem Studium.
Und jetzt haben wir tatsächlich auch diese Entscheidung getroffen, gemeinsam, dass er dann ab Herbst bei uns dauerhaft sein wird als Vollzeitkraft.
Und der hat, wie gesagt, eben gesagt, er möchte nicht eigentlich in die Hardcore-Entwicklung reingehen, weil das eigentlich nicht sein Ding ist.
Und als dann Agentik ums Eck kam und wir ihn dann damit losgeschickt haben und gesagt haben, probier mal, ob das was ist für dich, ob du damit klarkommst, haben wir erlebt, wie er eben voll in dem Thema aufgeht.
Und er ist jetzt einer von denen, die ganz nach vorne stürmen und das Thema ganz nach vorne treiben.
Und er hat auch die Plattform maßgeblich mitentwickelt und treibt die auch weiter voran.
Und das ist auch der Vorteil dieser dieser eigenen Plattform für die Entwicklungsverwaltung.
Wir können das, was wir an Features brauchen, einfach dazu bauen.
Oder wenn wir nochmal ein Labeling oder irgendwas brauchen, dann ist das einfach schnell dazu gebaut.
Wenn wir über Atlassian oder andere gehen würden, dann müssten wir da immer schauen, wie wir es organisieren.
Ich glaube, ich muss das auch nochmal hervorheben, wie krass das ist.
Wir reden von einem Tool, was ein de facto Standard ist in der Softwareentwicklung in den letzten 10 Jahren, 15 Jahren, Jira.
Und dann kommt ein Student und der ersetzt das innerhalb von einer Woche.
Also wenn man das mal so ganz pauschal dann sagt, das ist echt krass.
Also das betrifft aber nicht nur Jira, das betrifft natürlich sehr viele Software-as-a-Service-Companies, die sich jetzt überlegen müssen, was habe ich denn eigentlich noch für einen...
Wettbewerbsvorteil gegenüber einem Kunden, der jetzt sagt, naja, ich baue mir meine Lösung maßgeschneidert auf mich selbst und das passt dann besser zu mir, anstatt dass ich da jetzt für meine Leute über die Jahre hinweg Zehntausende Euro an Lizenzgebühren halt zahle.
Da gehen ganze Geschäftsmodelle den Bach runter.
Oder zumindest es sieht so aus, als würde es in eine Richtung gehen, in der diese Geschäftsmodelle sehr massiv gefährdet sind.
Ja, richtig.
Wir haben ja als SaaS-Kompany die gleiche Fragestellung nach vorne.
Das trifft uns ja genauso.
Und auch da ist es natürlich so, dass wir auch den Markt beobachten, dass wir da auch Dinge sehen, die uns nicht unbedingt auf den ersten Blick gefallen.
Und wir haben dann Strategien, über die ich jetzt auch gar nicht im Detail reden möchte, was dann doch sehr tief ins Nähkästchen reingeht.
Aber vielleicht können wir aber Folgendes machen.
Ich habe nämlich tatsächlich auch ein Problem, das betrifft sogar eure Kernexpertise.
Dann können wir das mal als Beispiel nehmen.
Und zwar, ich mache auch Marketing, ich habe auch ein CRM, ich habe Kundendaten, E-Mails fliegen in verschiedenen Systemen rum, ich nutze ein Hubspot, ich nutze ein Kit für E-Mail-Marketing und so weiter und so fort.
Und ich habe auch das Problem, ich habe...
eine fragmentierte Landschaft an verschiedenen Sachen.
Das funktioniert für mich aktuell und ich habe mir immer gesagt, naja, wie konsolidiere ich jetzt das am besten?
Gehe ich jetzt vollständig auf den Hubspot und mache halt da irgendwas, aber das ist mir alles irgendwie zu groß und zu viel und zu kompliziert.
Und eigentlich bin ich jetzt gerade an dem Punkt, an dem ich auch überlege, ich baue mir jetzt einfach selber was.
Also kann ja nicht so schwer sein.
Im Gegenteil, wahrscheinlich ist es sogar erst mal recht einfach, das Thema ein kleines CRM für mich zu machen, das Thema die Leute richtig zu taggen, abhängig von irgendwelchen Meetings, die sie mit mir hatten, E-Mail-Marketing daraus zu triggern, was auch immer.
Ich stehe jetzt an dem Punkt, an dem ich aktiv plane und einen Backlog fülle, mir sowas selber zu bauen.
So, jetzt habe ich eben vorhin natürlich auch in Vorbereitung auf den Podcast heute nochmal bei euch geschaut und habe gedacht, naja, vielleicht bietet ihr mir ja an, was ich halt irgendwie möchte.
Warum sollte ich jetzt euch nutzen, anstatt mir was selber zu bauen?
Das ist jetzt die Möglichkeit für dich, live zu pitchen.
Jawohl, das mache ich gerne.
Also, eine Software zu bauen, die schnell funktioniert, die bei 80 Prozent des gewünschten Funktionsumfangs ist, das haben wir vorhin schon herausgearbeitet, das funktioniert recht schnell.
So, und dann geht es in die vielen Details rein und dann kommen wir auch an den Punkt, an dem das Ding weiterentwickelt und weitergewartet werden muss.
Und an dem Punkt, wo du einfach damit arbeiten möchtest, also am Anfang bist du in so einer Hype-Phase dran, da machst du das so.
Und dann kommst du irgendwann an den Punkt, da möchtest du damit arbeiten, da möchtest du, dass es funktioniert.
Was du vielleicht gar nicht so merkst, ist, dass dein Bedarf sich weiterentwickelt, dass du dich weiterentwickelst, dass deine Daten aber nicht mit dir mitwachsen und deine Datenstrukturen nicht mit dir mitwachsen.
Und dieses...
Weiter mitwachsende Datenstrukturen, dieses Weiter mitwachsende Systems, das ist etwas, um das du dich dann aktiv kümmern musst.
Das heißt, du machst dir dann eine dauerhafte Baustelle auf, die du betreuen musst, die du dauerhaft auch begleiten musst.
Und das ist etwas anderes, als ich baue mal schnell in drei, vier, fünf Tagen eine Lösung, sondern das ist etwas, was dauerhaft Last produziert.
Und gerade als kleine Organisation hat man diese.
Möglichkeiten nicht, hat auch diese Zeit, diese Kapazität nicht.
Man möchte im Fokus bleiben eigentlich.
Man möchte eigentlich in seinem Business unterwegs sein.
Und dann kommt der Punkt nach ein, zwei, drei Jahren oder vielleicht auch noch schneller, an dem man sagt, okay, nee, also war jetzt nett, aber bringt mich nicht wirklich nach vorne, weil ich defokussiere da an der Stelle.
Ich schaue mich vielleicht doch wieder nach einem Standardsystem um.
Und das ist etwas, was große Organisationen, wie wir sie bisher im Kundenportfolio haben, schon wissen und gelernt haben, dass es an der Stelle viel, viel mehr Sinn gibt, auf die Erfahrung eines Anbieters zu setzen, der in der Branche unterwegs ist.
Das ist auch ein Spezifikum von uns, also eine charakteristische Eigenschaft von uns, dass wir in spezifischen Branchen unterwegs sind, dass wir dieses Wissen aus den Branchen haben.
Wir sind im Moment sehr stark im Kulturbereich unterwegs, sehr stark im Tourismus unterwegs, haben die größten Kulturhäuser Europas in unserem Kundenstamm.
vor allem im deutschsprachigen Raum.
Also das sind die Elbphilharmonie, das Wiener Konzerthaus, das Opernhaus Zürich nur drei, aber viele, viele andere namhafte auch noch.
Und diese Expertise, die wir da haben, die führt ja auch dazu, dass wir Funktionen bauen mit dem Wissen, das wir aus diesen Kundenprojekten heraus generieren.
Also wir sorgen dafür.
dass auch ein gewisser Standard in der Branche dann zum Tragen kommt, der auch anderen aus der Branche, die vielleicht noch nicht an einem Punkt angekommen sind, den ein anderer Kunde schon erreicht hat, weiterhilft.
Ich teile deine Einschätzung.
Ein bisschen ist im Widerspruch natürlich zu dem, was ihr, ihr baut ja selber ein Jira nach, oder indirekt.
Eigentlich müsstest du dann ja auch sagen, naja, ist das denn jetzt so sinnvoll, weil später brauchen wir, jetzt müssen wir uns die ganze Zeit darum kümmern.
habt euch trotzdem dafür entschieden.
Ich glaube, für euren Fall ist es doch nochmal anders, weil eure Zielgruppe sehr wenig technikaffin ist oder sehr wenig softwareentwicklungsaffin ist und dementsprechend vielleicht selber auch gar nicht sich traut oder gar nicht auf die Idee kommt, so etwas überhaupt selber bauen zu können, weil dafür, ja, du brauchst vielleicht doch nochmal jemanden, der versteht, wie Softwareentwicklung grundsätzlich funktioniert, damit was Sinnvolles dabei rauskommt.
Ist das vielleicht nochmal so die große Unterscheidung und vielleicht der große Difference Maker für ein Unternehmen wie euch, dass ihr in einer Branche seid, die euch nicht das Wasser abgraben kann?
Ihr seid in der Branche, also eure Entwickler sind in der Branche, ihr könnt einem Jira das Wasser abgraben und ihr könnt es selber bauen, weil ihr die Kernkompetenz dafür im Unternehmen habt.
Eure Kunden haben das wahrscheinlich nicht.
Das ist sicherlich ein Teil der Erklärung, ja.
Ein anderer Teil der Erklärung ist, Dass wir gelernt haben oder auch uns danach orientieren, die Dinge, die wir tun, wollen wir immer auf ein möglichst allgemeingültiges technisches Level heben.
Letztlich ist eine Anforderung, die ich als Entwickler habe oder eine Aufgabe, die ich als Entwickler zu erledigen habe, eben eine Aufgabe, die ich als Entwickler zu erledigen habe.
Also ein Feature, das ich möchte, ist letztlich eine Aufgabe, die ich in der Entwicklung zu erledigen habe.
Versus wenn eine Kundenanfrage reinkommt bei unseren Kunden.
dann ist das auch eine Aufgabe, die in der Organisation des Kunden zu erledigen ist.
Und auf dem Level gesehen sind wir dann auf einmal bei einer Funktion, die wir ohnehin im KM-Produkt brauchen.
Dann kann ich auch mein Produkt, das ich selber baue, für mich selbst verwenden und nicht nur für Marketing, sondern auch für andere Aufgaben.
Wir haben da einen Slogan bei uns im Unternehmen, der heißt Eat your own bread.
Es ist dein eigenes Brot.
Und das als erstes.
Ja, kenne ich auch noch von anderen Unternehmen, denen ich früher war.
Hieß es auch Eat Your Own Dog Food.
Geht ja in die ähnliche Richtung.
Sehr gut.
Ja, aber ich glaube, diese Unterscheidung ist schon wichtig, auch vor dem Hintergrund, welche Unternehmen bieten jetzt nochmal auch zukünftig welchen Mehrwert im SaaS-Umfeld.
Siehst du eine allgemeine?
Oder wie ist denn dein allgemeiner Blick auf das SaaS-Thema?
Wenn ich mir die Börsenkurse anschaue, da ist da sehr viel Ungewissheit, die gerade eingepreist wird.
Sobald es nochmal neue Entwicklungen geht, gehen die Kurse von SAP und Salesforce und sowas in den Keller, was ein Zeichen für die steigende Unsicherheit ist.
Wir werden mit Sicherheit keine SaaS-Apocalypse sehen, dass jetzt alle SaaS-Unternehmen der Verdammnis anheimfallen.
Auf der anderen Seite hat es ja schon einen disruptiven Charakter.
Wie ordnest du das so global galaktisch ein?
Also die Unternehmen, die genau ein Problem lösen und dafür eine SaaS-Applikation gebaut haben, das sind diejenigen, die als erstes an Probleme stoßen werden, nämlich, dass man sie einfach nachbauen kann.
Also das Erstellen von Code als solches hat heute keinen Wert mehr.
Vor einem Jahr hatte das noch einen Wert, heute hat es keinen Wert mehr.
Das tut mir leid, das so aussprechen zu müssen, aber es ist so.
Heute hat die Fähigkeit gewonnen, dass man Business-Prozesse, Geschäftsprozesse, dass man die gut abbilden kann.
Und zwar ohne das, was du vorhin bei dir selber beschrieben hast, zu haben.
Nämlich, dass man x Schnittstellen hat und x Systeme miteinander verbinden muss.
Man muss eine logische Abfolge haben für Geschäftsprozesse, um die für die Kunden dann so abzubilden und zugänglich zu haben, dass sie gut damit arbeiten können.
eben bei einem logischen Anfang bis hin zu einem logischen Ende des Prozesses.
Dann, wenn man das abbilden kann, dann hat man ein gutes Asset.
Das ist meine jetzige Einschätzung.
Das kann sein, dass ich in zwölf Monaten etwas ganz anderes sage, aber das ist aufbauend auf dem Wissen, das wir heute haben.
Meine Meinung.
Wie gesagt, je einfacher die Anwendung ist, umso eher ersetzbar wird sie.
Gehst du allgemein mit Mit Unsicherheit bei dir im Team und wenn sich so fundamental etwas verändert.
Du hast jetzt ein Beispiel genannt, mit einem, dem es sehr zugutekommt, diese neue Art zu arbeiten.
Es gibt aber vielleicht auch den anderen Mitarbeiter, der sich sehr stark darüber definiert hat, sehr tiefes Detailwissen über Implementierung, über Effizienz und so weiter, sich damit seine eigene Identität als Softwareentwickler sehr stark darüber definiert.
Dessen Identität wird dadurch gerade massiv angegriffen.
Wie gehst du mit solchen Unsicherheiten im Team dann um?
Oder hast du das in der Form gar nicht, weil es dieses Extrem bei euch oder bei euch im Unternehmen gar nicht gab als Engineering-Typus?
Ja, wir haben schon auch den Typus im Team, der sehr auf die Detaillierung hinarbeitet, der sehr in die Tiefe geht.
Die braucht es ja auch weiterhin.
Also ich brauche ja für bestimmte Problemfälle oder Fragestellungen, brauche ich ja auch Menschen, die bereit sind, sich tief einzugraben.
weil die KI das nicht beherrscht, weil da noch der Kontext fehlt, weil da das Training der KI noch nicht tief genug ist, was auch immer.
Das kann sich und wird sich natürlich auch im Laufe der nächsten Monate und Jahre auch nochmal verändern.
Im Moment ist es so, dass wir da an der Stelle immer noch das Menschenwissen brauchen und das haben wir mit diesem Typus auch im Team.
Darüber bin ich sehr froh.
Und auch die Menschen, die das betrifft, nehmen wir mit.
befähigen sie im Umgang mit der Gentic und versuchen mit denen zusammen herauszuarbeiten, wo in Zukunft ihre Schwerpunkte liegen können.
Das Thema Personalentwicklung ist bei uns, ich habe es schon mal gesagt vorhin, ist ein ganz, ganz wichtiges Thema für uns.
Also die Kommunikation mit den Menschen, die Ängste zu verstehen, die da jetzt auch da sind.
Und das betrifft nicht nur die Entwicklerinnen und Entwickler, das betrifft auch meine liebe Kollegin, die bei uns das Backoffice macht, die auf einmal hört, okay, ein Teil ihrer Tätigkeiten wird automatisiert.
dann muss ich mit ihr einfach darüber sprechen, wo ich in Zukunft ihre Rolle sehe und muss ihr die Sicherheit geben, dass sie auch in Zukunft im Unternehmen gebraucht wird und dass sie da nicht nur irgendwie Dinge von A nach B trägt, sondern auch sinnvolle Dinge tun kann.
Und so schaue ich gerade auf der technischen Ebene, dass ich die Rollen weiterentwickele und wir schauen als Unternehmen.
Insgesamt darauf, dass wir die Rollen der Menschen im Unternehmen weiterentwickeln in die Zukunft.
Wie entwickelt ihr die konkret weiter?
Also ich verstehe, es ist ein bisschen eine Gratwanderung zwischen Psychologie, gut zureden, Lösungsräume anbieten, in die man reingehen kann.
Andere Unternehmen sagen einfach, ja, hier hast du eine Cloud-Code-Lizenz, viel Spaß, das ist deine Weiterentwicklung.
Wie macht ihr das?
Also einmal sind es fachliche Trainings, tatsächlich den Umgang mit Claude und Co.
schulen, den Menschen Erfahrungen geben, aber dann auch wiederum schauen, also den Menschen Erfahrungen ermöglichen und dann aber auch schauen, dass sie jemanden an der Hand haben, der sie da begleitet in dem Prozess, aus dem Team, der schon mehr Erfahrung hat, aber auch die Nutzung von Online-Sessions, die man einfach...
Masterclasses oder was auch immer nutzen kann, um sich da weiterzubilden zu dem Thema.
Also das Thema Fortbildung, Weiterbildung in Form von Lernplattformen, das ist ein ganz relevanter Baustein, um die Menschen damit zu befähigen, umzugehen.
Und das andere ist eben auch, wir haben für jede Rolle schriftlich ausgearbeitet, wo die Tätigkeiten liegen, was die Erwartungshaltungen sind.
Für jemanden, der es vielleicht schon mal gehört hat, wir arbeiten im Unternehmen mit OKRs und OJRs, also Objective Key Results und Objective Job Results.
Und die haben wir schon nach vorne transportiert, soweit uns das heute möglich ist, das abzuschätzen, wo sich das hin entwickeln wird.
Und die gibt es für jeden auch nachzulesen im Intranet.
Du hast auch eben noch ein Thema angesprochen, was man in mehrere Richtungen interpretieren kann.
Du hast angedeutet ja auch, Softwareentwicklung ist, oder Codeschreiben ist kein Engpass mehr, hast du sinngemäß gesagt.
Das ist 100% richtig.
Es gibt sehr viele, die dann gerade das weiterspinnen und dann sagen, Softwareengineering steckt in einer Krise.
Und an dem Punkt, ich weiß nicht, wie du das siehst, an dem Punkt würde ich einhaken und würde sagen, das sehe ich nicht so, ganz im Gegenteil.
Ich sage, glaube ich, Softwareengineering wird gerade...
die nächste neue Hype-Phase auf sie zu steuern.
Was in der Krise ist, ist die Rolle des Software-Ingeniers, weil der sich jetzt fundamental verändern muss, anpassen muss an diesen neuen Begebenheiten und das, was vorher wichtig war, ist jetzt weniger wichtig, weil sich der Engpass verschiebt.
Trotzdem wird natürlich in der Summe wesentlich schneller, wesentlich mehr Code generiert werden in den nächsten Jahren als jemals zuvor.
der wird nur nicht mehr von Menschenhand geschrieben werden im Großteil.
Und das ist für mich dann keine Engineering-Krise, sondern es ist eine Krise der Rolle des Engineers.
Siehst du das ähnlich oder wo würdest du da nochmal einen anderen Ansatz nehmen?
Ich sehe das so wie du.
Das Engineering als Tätigkeitsfeld, da ist keine Krise.
Das hat einfach die nächste Stufe in der Weiterentwicklung, in der Evolution erreicht.
Wir haben heute andere Werkzeuge an der Hand.
Das ist so ein bisschen, ich bemühe da gerne auch in den Gesprächen mit dem Team und aber auch mit Gesprächen mit Menschen, die vielleicht nicht so nah am Thema dran sind in meinem Umfeld, gern das Bild der Industrialisierung im 19.
Jahrhundert.
Damals gab es viele Handwerker, die in Kleinarbeit, ich nehme mal den Schmied heraus, der in Kleinarbeit in seiner Zuhause, Werkstatt, wo auch immer, stand und da geschmiedet hat und dann am Ende toll geschmiedetes Metallteil gefertigt hat.
Und dann kam die Industrialisierung mit den Werkhallen, mit den Fabriken, mit den Maschinen, die dann immer feiner ausgearbeitet wurden.
Und was es heute braucht, ist nicht den Schmied, der dasteht und am Ende das Werkstück hat, sondern es ist jemand, der eine Maschine bedient, der ein voller Automat bedient, der drehen, fräsen, bohren, was auch immer kann.
Aber da braucht es genauso dieses nicht das gleiche Wissen, wie es der Schmied gebraucht hat, aber es braucht genauso in einem gewissen Umfang Fachwissen, um zum Ziel zu kommen, um zum Werkstück zu kommen.
Und so ist es auch in der Softwareentwicklung.
Die Rolle des Entwicklers hat sich weiterentwickelt.
Das ist heute der Dirigent, der die Agenten orchestriert und nicht mehr derjenige, der den Coach schreibt.
Aber am Ende des Tages ist das Stück Software, das rauskommt, das relevante Ergebnis.
Und da braucht es Menschen, die dafür sorgen, dass das rauskommt.
Das ist richtig.
Wie stehst du zu dem Begriff der Softwarefabrik?
Ich habe das durchaus schon im eigenen Kundenumfeld erlebt, dass diese Begrifflichkeit verwendet wird, auch um das zu beschreiben, was Agentic AI zukünftig sein wird.
Das geht ja in eine ähnliche Richtung, was du beschrieben hast.
Ich habe mich mit dem Begriff gedanklich noch nicht auseinandergesetzt.
Ich habe jetzt also keine Meinung.
Softwarefabrik.
Oder lass mich das dann mal anders formulieren.
Fließbandarbeit, die wir da haben.
Du hast ja selbst den Begriff der Industrialisierung mit reingebracht.
Dementsprechend wäre das ja vielleicht der logische nächste Schritt.
Sei mal dahingestellt, ob sich das so entwickeln wird oder nicht.
Aber was glaubst du denn, was verändert sich denn mit der nächsten Stufe?
die jetzt erreicht wird im Bereich der Softwareentwicklung in den nächsten 12 bis 24 Monaten?
Ja, wir werden sehr viele Automatisierungen erleben und zwar komplexe Automatisierungen, also einfach If-This-Then-As-Geschichten.
Also es wird einfach sehr viel mehr auch kontextbasiert automatisiert werden können.
Das ist das, was ich erwarte.
Das heißt...
Durch den Einsatz von der GenTik AI wird jetzt erstmal im B2B-Umfeld ganz viel, sehr viel automatisierter stattfinden.
Und dann wird es überschwappen auf den persönlichen Bereich, also auf den Konsumentenbereich.
Das ist noch nicht wirklich da, aber ich erwarte, dass das in den nächsten 12 bis 24 Monaten auf den Mobile Devices ankommt, das Thema Automatisierung und GenTik.
Und dass wir dann an der Stelle sehr viele Möglichkeiten haben werden, um auch da wieder als Konsumenten zu automatisieren und unseren eigenen Alltag effizienter zu gestalten.
Was unterschätzen aktuell die meisten CTOs beim Thema Agentic AI?
Ein bisschen schwer zu sagen, weil ja jeder so seine eigene Brille hat.
Also ich möchte jetzt gar nicht so für die Allgemeinheit der CTOs sprechen.
Mir geht es so, dass ich ständig neue Potenziale erkenne in dem Thema Agentic.
Das heißt eigentlich jeden Tag geht nochmal irgendwo und wenn es nur ein kleines Spielfältchen ist, irgendwas auf, irgendeine Tür auf, von der ich sage, da ist es auch noch gut, wenn wir das verwenden.
Und das heißt, dass die Technologie als solches noch am Anfang ihrer Möglichkeiten steht, beziehungsweise am Anfang ihrer Möglichkeiten genutzt wird.
Und ich glaube, dass das etwas ist, was nicht nur mir so geht, sondern das wird wahrscheinlich da draußen auch noch zwei, drei anderen Menschen so gehen.
Vermutlich mehr als zwei, drei.
Das heißt, dieses Potenzial, das da da ist, das zu erkunden, das ist eigentlich heute die Hauptaufgabe eines CTOs.
Ja, da gehe ich auf jeden Fall mit.
Michael, wir sind fast am Ende der Aufnahme angelangt.
Und als du das erste Mal bei uns warst, gab es, glaube ich, das mit den Rapid-Fire-Fragen noch nicht, was wir mittlerweile eingeführt haben.
Das ist neu für mich.
Das ist neu für dich, genau.
Aber ich habe ein paar Rapid-Fire-Fragen mitgebracht.
Wenn du noch ein paar Minuten Zeit hast, können wir da rein.
Ja, klar.
Sehr schön.
Was ist für dich die größte Misconception über Agentic AI?
Sie ist kein Allheilmittel.
Also, wer sie als Allheilmittel versteht, wird eine Enttäuschung erleben.
Ein Tool, ohne dass du aktuell nicht mehr arbeiten kannst, willst?
Jetzt gerade Cloud Code.
100 Prozent.
Wobei ich auch jetzt gehört habe, Codex muss gerade auch nochmal einen Schritt nach vorne gemacht haben.
Aber da darf man sich auch nicht vom FOMO beeindrucken lassen und denken, man muss jetzt jeden Quatsch ausprobieren und immer von Tool zu Tool springen.
Anyways, glaubst du, Agentic AI ist aktuell overhyped oder immer noch massiv unterschätzt?
Unterschätzt.
Sehr gut.
Gehe ich auch mit, ehrlich gesagt.
Auch wenn noch viele noch gar nicht das ausgenutzt haben, was aktuell schon möglich ist.
Genau.
Und ich glaube einfach immer noch halt das, was ich gerade vorhin gesagt habe.
Es gehen jeden Tag irgendwo neue Türchen und Fensterchen auf.
Sehr richtig.
Was ist denn der eine Skill, den Entwickler jetzt lernen müssen?
Das Zusammenspiel von Agenten.
Das zu beherrschen.
Die Orchestration von Agenten.
Das ist das, was heute in der Entwicklung gefordert wird und in Zukunft notwendig sein wird.
Ich bin mal übrigens gespannt, wie schnell sich Universitäten und Lehrpläne an sowas anpassen, weil die, die jetzt aktuell in der Ausbildung oder im Studium befinden, können sich die Lehrpläne so schnell anpassen?
Sind die so agil und flexibel, dass sie darauf reagieren können?
Weil ansonsten haben die Leute echt ein Problem, wenn sie rauskommen in einem Jahr oder zwei und noch gar nicht auf das vorbereitet sind, was da passiert.
Also in Bezug auf Lehrpläne kann ich und möchte ich da gar keine Provenzen abgeben, aber einen Erfahrungswert aus der Praxis, den habe ich zur Hand.
Der Sohn eines Entwicklers war neulich für einen Semesterferienjob bei uns, hat da seine allerersten Erfahrungen gemacht, hat die jetzt übertragen in sein Studium und der Papa kam jetzt neulich zu mir und hat davon berichtet, dass sowohl der Sohn als auch seine drei, vier mit Studenten, mit denen er da regelmäßig sich trifft, dass die Projekte damit gestimmt haben und die studieren alle keinen Informatik, die studieren, ich glaube, VWL oder sowas war es und die haben echte Ergebnisse gehabt, die er mir auch zeigen konnte und das war echt beeindruckend.
Das bringt mich auch zur letzten Frage für heute.
Wird ein Team mit fünf Engineers bald so viel liefern wie früher?
20.
Die 20 von früher werden bald so viel liefern wie 100.
Oder so, ja.
Also ja.
Ja, genau.
Ich will aber nicht, also was mir wichtig ist, ist, dass ich dabei nicht davon ausgehe, dass die Arbeitsplätze einfach wegfallen werden, sondern dass die Steigerung der Effizienz im Vorbaugrund steht.
Das ist richtig.
Wobei ich auch noch unsicher bin, ob wir wirklich mehr Leute in Engineering sehen als früher.
Oder ob wir einfach auf dem Level erstmal bleiben und vielleicht leicht steigen, aber nicht viel.
Also ich bin immer, ich wage die These, dass wir vielleicht Peak Engineering gesehen haben, im Sinne von wie viele Leute in Engineering angestellt sind.
Brauchst du da wirklich in einem großen Unternehmen wirklich Hunderte von Software Engineers noch?
Oder gehen das nicht auch ein paar Dutzend?
Das ist dann die große Frage.
Genau.
Das wird die Zukunft zeigen.
Sehr schön.
Wir sind sehr gespannt und dann reden wir ein weiteres Mal miteinander, Michael.
Ich finde das sehr spannend, was bei euch in den letzten Monaten passiert ist, gerade auch nachdem wir gesprochen haben, als wir gesprochen haben.
Da war das noch vor dieser Entwicklung.
Da wart ihr auch noch vor Launch, wenn ich mich noch recht erinnere.
Da hat sich seitdem einiges bei euch getan.
Ich glaube, ihr seid, wenn ihr vor acht Monaten gestartet seid, wirklich sehr, sehr weit der Zeit voraus.
Die meisten Unternehmen fangen jetzt erst an, sich damit aktiv auseinanderzusetzen.
Ich glaube, das ist auch ein Wettbewerbsvorteil, den ihr habt, ein Vorsprung, den ihr auch gut nutzen könnt.
Deswegen danke für deine Einblicke heute.
Sehr interessant.
Und ich bin gespannt, wo wir in den nächsten Dreivierteljahr stehen werden.
Dann kommst du nochmal und erzählst, wie es weiterging.
Sehr gerne.
Danke für die Einladung und unser tolles Gespräch.
Sehr schön.
Michael, mach's gut.
Ciao, ciao.
Ciao, Philipp!