#50 Jira raus, Agenten rein: Wie ein Werkstudent in einer Woche das Dev-System neu gebaut hat

Was passiert, wenn ein SaaS-Produkt kurz vor dem Launch steht – und das Team entscheidet, die Entwicklung radikal auf Agentic AI umzustellen?

In dieser Folge von Becoming CTO Secrets spricht Philipp Deutscher mit Michael Reimann über eine Entscheidung, die viele CTOs wahrscheinlich vermeiden würden: Vier Wochen vor dem geplanten Launch stellte sein Team die Entwicklung massiv auf Agentic AI um.

Das Produkt war bereits weit fortgeschritten, doch ein Entwickler zeigte nach einem Wochenende, was mit agentischer Entwicklung plötzlich möglich war. Danach war klar: Klassisch weiterzumachen hätte bedeutet, Geschwindigkeit und Potenzial liegen zu lassen.

Im Gespräch geht es um konkrete Erfahrungen aus der Produktentwicklung: Was funktioniert wirklich? Wo entstehen neue Risiken? Wie verändert sich die Rolle von Entwicklern? Und was bedeutet es, wenn Features, die früher zwei Monate gebraucht hätten, plötzlich in zwei Tagen entstehen?

Michael spricht offen über Regressions, Quality Assurance, Kontextprobleme, neue Rollenprofile, Claude Code, React-Entscheidungen durch AI, den Abschied von Jira und die Frage, ob klassische SaaS-Geschäftsmodelle durch Agentic AI unter Druck geraten.

In dieser Folge erfährst du:

•  Warum Michael und sein Team vier Wochen vor Launch auf Agentic AI umgestellt haben 
•  Welche Risiken durch den Umbau von Frontend und Backend entstanden sind 
•  Warum die letzten 20 Prozent weiterhin schwierig bleiben 
•  Wie sich Softwareentwickler vom Coder zum Orchestrator von Agenten entwickeln 
•  Warum Kontext der entscheidende Engpass in agentischer Entwicklung bleibt 
•  Wie sich Velocity, Rollenprofile und Personalplanung verändern 
•  Warum ein Werkstudent innerhalb einer Woche eine eigene Jira-Alternative bauen konnte 
•  Weshalb Michael glaubt, dass Code schreiben als solches kaum noch Wert hat 
•  Was CTOs beim Thema Agentic AI aktuell unterschätzen 

Eine Folge für CTOs, Tech Leads, Engineering Manager und alle, die verstehen wollen, wie Agentic AI Softwareentwicklung, Organisation und SaaS-Geschäftsmodelle verändert.

Transcript

SPEAKER_00 0:00

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 meistdiskutierten 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 ist CTO von Starmade, einem Produkt, CRM und E-Mail für 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.

SPEAKER_01 1:05

Ja, danke schön für die Einladung, Philipp.

SPEAKER_00 1:08

Sehr 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 habt seit ein Risiko eingegangen, das 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?

SPEAKER_01 1:27

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 wird die 100 werden wir wahrscheinlich nicht ganz auf den Termin schaffen, den wir uns vorgenommen hatten. Es wird wahrscheinlich eher so auf die 97% 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 parial, das, was er ums Eck gebracht hat, war eben entwickeln mit Utentic AI. Er hatte da übers 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 drauf 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 erstmal weiterverfolgen und die Möglichkeiten und auch die Grenzen von Agentec AI ausloten wollen für uns, für unseren Zweck, für die Produktentwicklung. Und dann haben wir das für einen begrenzten Zeitraum weitergenutzt. 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.

SPEAKER_00 3:02

Und 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 der im ersten Moment das sehr ansprechend aussieht, was da passieren kann, ist es ja doch ein größerer disruptiver Eingriff.

SPEAKER_01 3:24

Absolut, ja. Also das Frontend wurde am Ende des Prozesses dann zu 100% getauscht. Im Backend gab es auch gravierende Änderungen, also zu einem erheblichen Anteil. 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 haben, den wir zu dem Zeitpunkt hatten, zu dem wir entschieden haben, dass wir jetzt erstmal auf Gente AI umsetzen. Und damit hätten wir uns für Teilnahme 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 Gesellschafter-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 Release-Tag dann mehr oder weniger blank, mit nur dem Ergebnis, dass 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 und zwar das Potenzial von Algentic eigentlich voll bewusst. Mit dem ersten Moment, in dem wir es gesehen haben, was da möglich ist, haben wir gesagt, okay, das 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 St. Cost Fallacy auch völlig im Klaren oder waren wir uns völlig bewusst über den und haben den, haben dann entschieden, oder dann habe ich eben entschieden, dass wir das jetzt aktiv auf die Schiene bringen, mit dem Risiko nicht voll terminreu liefern zu können. Aber es gab ja einen sehr guten Grund dafür.

SPEAKER_00 5:26

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 Startschuss für Agentic 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 es ein bisschen genauer beschreiben, was ihr da schon hattet? Also war es, 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.

SPEAKER_01 6:14

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 ja wirklich klassisch unterwegs. Also unsere Entwickler, ja, die haben schon mal wie mit Gemini oder ChatGPT oder auch einem Cloud gearbeitet und haben da von Hand Abfragen reingeworfen oder Prompts reingeworfen und haben das dann entsprechend Code generieren lassen, rausgenommen. Und der Breakthrough war eigentlich das eben das agentische Vorgehen dann in dem Fall auf den verschiedenen Modellen, die da zum Einsatz kamen, unter anderem auch Claude, 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.

SPEAKER_00 7:30

Gab es dann trotzdem noch einen Punkt, an dem du dachtest, oh, das fliegt uns jetzt komplett um die Ohren?

SPEAKER_01 7:36

Den gab es. Der Pareto ist ja auch hier mit an Bord, also sprich das 8020-Prinzip. Und das hatte ich so nicht auf dem Schirm, natürlich nicht. Wenn man zwar am Anfang die bunte Kiste 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 da klassische Prinzipien dann über Bord geworfen werden können. Und das ist nicht so. Der ist an Bord der Pareto und dem muss man auf dem Zettel haben. Du brauchst hinten raus immer noch diese 80% deiner Entwicklungszeit für die letzten 20% der Leistung. Und als wir bei diesen letzten 20% angekommen sind, da hatte ich dann schon so immer wieder Situationen, in denen ich dachte, okay, das fliegt dann so um die Ohren, das kriegen wir mit diesen neuen Mitteln überhaupt nicht mehr in 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 erst 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 und das zyklisch, sodass wir immer wieder sicher gehen konnten, dass wir alles getestet haben, auch das Zusammenspielen, 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.

SPEAKER_00 9:56

Wie nimmst du denn oder wie hast du denn Entwickler mitnehmen müssen, gerade in der ersten Phase? Du hast gesagt, er ist ja ein Entwickler, ist sehr proaktiv auf dich zugekommen und hat dir gezeigt, was er damals jetzt schon machen kann. Das sind ja wahrscheinlich mehr wie ein Entwickler in der Company und vielleicht ist auch nicht jeder genauso progressiv oder genauso begeistert, was den Einsatz von Agenc AI oder LLMs angeht. Gab es kritische Stimmen im Unternehmen und wie hast du die mitgenommen?

SPEAKER_01 10:23

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 das ist so ein Hinweis 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 hat das nicht funktioniert. Das ist wie immer im Change. Wenn es aus dem Team herauskommt, dann ist da eine gewisse Motivation da. Und wir haben, ja, wir haben das unheimliche Glück auch und 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 wird 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 Stempel aufgedrückt haben. Und dieses, wir entwickeln jetzt mit einer KI, mit der wir methodisch vorwärts kommen, mit einer Gente-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 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 Orchestri, die Agentic-KI orchestrierst, dass du die Agenten orchestrierst, dass du eben dafür zuständig bist, dass das, was die rausfinden, 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 da 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 diesen Jahres noch jemanden leisten in der Entwicklung, also Stellen ausschreiben. Und das haben wir dann erstmal zurückgestellt. Wenn wir gesagt haben, wir können im Moment gar nicht einschätzen, wohin die Reise überhaupt geht für uns. Also wir wussten nicht, wen wir brauchen, was diese Person an Fähigkeiten haben muss. Und haben dann deshalb die Entscheidung erstmal zurückgestellt, um sie jetzt wieder zu treffen und tatsächlich etwas verändert auszuschreiben.

SPEAKER_00 14:01

Okay, wir hatten 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?

SPEAKER_01 14:25

Also wir suchen jemanden oder wir suchen jetzt Menschen, die Erfahrung haben im Umgang mit KI, die Erfahrung 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 Code-Verstä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 Mikroarchitektur Gedanken. Ich muss Architektur als Ganzes verstehen. Ich muss die Systeme verstehen, die da zusammenspielen. Ich muss 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.

SPEAKER_00 15:36

Wenn man bei euch jetzt reinschaut, was ist denn da tatsächlich Agenk 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 agentic 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.

SPEAKER_01 16:11

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. Das heißt, dem braucht es immer am Ende des Prozesses. Auch wenn 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 dahinter stehen können. Und ansonsten ist es so, wir haben in der Entwicklung umgestellt, da ganz massiv, also die Entwicklung sieht heute ganz, ganz anders aus als vor acht Monaten. Vor acht Monaten haben wir klassisch entwickelt mit ein bisschen KI. Heute entwickeln wir Agentic mit, ah ja, ab und zu vielleicht mal noch einem händischen Eingriff, aber es ist eigentlich schon ziemlich wenig geworden, also fast 3-0. Die QS ist dabei, immer mehr Agenk aufzunehmen. Also da waren die ganzen Testszenarien, die werden immer mehr automatisiert, so dass wir da auch auf einem sehr, sehr guten Weg sind. Und dann ist es so, dass wir nicht nur SARS-Anbieter sind im Sinne von wir produzieren ein System und stellen das bereit, sondern wir stellen dazu auch, weil es ein B2B-System ist, eben Consulting-Dienstleistungen bereit. Das heißt, man kann bei uns das Onboarding buchen, man muss sich beraten lassen im Hinblick auf, wie muss eine technische Konfiguration aussehen oder ich habe ein Wunsch-Zielbild, 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 rein. 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, ja. 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 Atlantic automatisiert ist. Das bringt, 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 also 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 kommt man jetzt in Echtzeitberichte, das war früher nicht immer so.

SPEAKER_00 19:42

Ja, das glaube ich dir. Wie darf ich mir das trotzdem vorstellen? Also wie war der Grundgedanke beim Aufbau eurer Agentic-AI-Prozesse? War das dann ein Mensch, erstellt 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 Test schreibt und die Qualitätssicherung macht. Oder habt ihr das dann, 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?

SPEAKER_01 20:30

Ja. Also die Grundidee ist, den kompletten First-Level Support eben Attentic zu machen. Das heißt, kleine Fehler, die Kundenanfragen, die klar benennbar sind, die repetitiv sind, also sie wiederholend sind im Sinne von das haben Kunden immer wieder, das Thema, das wird das automatisiert gelöst bekommen. Tatsächlich stellt sich da eben heraus, der größte Stolperfalle, also dieser ganze administrative Prozess, that is kein Problem. Also Ticket-Label, Ticket-Clustern and 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 SARS-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 Basiss-Setup des Systems, dem Agenten zu füttern, sondern da muss er ein bisschen mehr Kontextwissen haben. Und das ist etwas, was noch ongoing ist, das zu vermitteln. Das haben wir uns ein bisschen einfacher vorgestellt.

SPEAKER_00 21:45

Wie gehst du mit dem Problem um, dass ein großer Unterschied zwischen einem Seniorentwickler heute und einer sehr guten AI oder einem sehr guten Agent ist meistens ja nicht das. Dass der Seniorentwickler 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, so ja, das wollte ich ja gar nicht, aber 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 denn Agents zur Verfügung?

SPEAKER_01 22:35

Sehr consequent. Also sobald we darauf stoßen, dass es ein Context-Scap gibt, wird das in Markdowns entsprechend notiert und dem Agent zur Verfügung gestellt, so dass 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, that we that auch tun. Also wir haben ein Ziel, wir haben, 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 auch 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. And this schlau machen, dieses effizient vorgehen, we wussten for two years by the gründung not, welches Werkzeug uns da helfen wird anders. But he wisons that Atentic a ganz, ganz wesently Baustein day. And in the sound and gegenseitig that ausgesprochen have, also that was not, was the CTO gesagt, but that came out aus democracy as Feedback, quasi zeitgleich in the gleich meeting. 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.

SPEAKER_00 24:20

Welche Use Cases haben sich dabei als echte Game Changer herausgestellt?

SPEAKER_01 24:24

Also das Vorgehen in der Entwicklung ist der größte Game Changer. Da haben wir die größte Geschwindigkeit. Das ist, also, ja, wenn ich heute überlege, wie wir vorgehen, wir haben jetzt jüngst erst eine sinnvolle Produktergänzung gebaut, die bei uns die Kunden schon vor Jahren sich gewünscht hatten. Also wir sind ja, 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 es auch to 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. Es wäre immer, also 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. Und ja, heute gehen wir jetzt her, haben die Möglichkeit über Agentic AI, entsprechend die Dinge, die wir da brauchen, zu entwickeln und entwickeln die auch.

SPEAKER_00 25:45

Kannst du, kannst du den Erfolg, den ihr jetzt mit Agenc AI habt, kannst du den quantifizieren, qualifizieren? Also im Sinne von wie sich eure Wort, Delivery Capabilities erhöht haben. Also habt ihr jetzt mehr Velocity, also habt ihr 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?

SPEAKER_01 26:16

Ja, Lines of Codes werden in dem Kontext so ein bisschen leider relevant. Vielleicht ist es die Velocity, die da als guter, guter Messwert geht. 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 eigentlich die Erkenntnis, die wir haben und den Geschwindigkeitszuwachs, den wir haben, ja.

SPEAKER_00 26:46

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?

SPEAKER_01 27:19

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

SPEAKER_00 27:53

War das aus Empfehlung der AI? Also hat quasi der Agent empfohlen, React zu nehmen und euch eine gute Begründung geliefert. Und was, okay. Was wäre die Alternative gewesen? Was hättet ihr gemacht? Plain JavaScript?

SPEAKER_01 28:08

Ja, genau, wir waren eigentlich mit Vanilla unterwegs, also Plain JavaScript unterwegs. Und die Empfehlung war dann, nehmt React, weil damit geht es doch deutlich schneller und einfacher und besser.

SPEAKER_00 28:20

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?

SPEAKER_01 28:49

Ja, also die Haupttätigkeit der Entwickler ist Orchestrierung 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 zum Dirigenten 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 Gira verabschiedet. Wir haben eine eigene Plattform am Laufen, die nahtlos in das Entwickeln mit Agentic eingreift und da auch die Befähigung herstellt. Wir haben eine eigene Plattform entwickelt dafür, als Randprodukt, als Nebenprodukt. Und darüber läuft es.

SPEAKER_00 30:17

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 Agentic AI-Stack zu integrieren?

SPEAKER_01 30:35

Ja, richtig, genau.

SPEAKER_00 30:37

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 du 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 da so eine eigene habt ihr dafür dann auch nochmal ein paar Wochen gebraucht, um sowas zu bauen oder war das dann innerhalb auch für innerhalb von ein, zwei Tagen dann quasi so eine Art MVP am Start und damit seid ihr einfach losgerannt?

SPEAKER_01 31:23

Ja, letzteres. Also innerhalb von, ich glaube, einer Woche stand der MVP. Wir haben dafür auch einen Waldstudenten, 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 als Waldstudenten vor zwei Jahren bei der Unternehmensgründung direkt an Bord geholt. Er hat sich im Bereich QS bewegt, hat aber auch entwickelt und war da so mit 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 der Kunden, 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, wenn das eigentlich nicht sein Ding ist. Und als dann Atlantic 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 jemand, 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 ja auch weiter voran. Und das ist auch der Vorteil dieser eigenen Plattform für die Entwicklungsverwaltung. Wir können das, was wir an Features brauchen, einfach dazubauen. Oder wenn wir nochmal ein Labeling oder irgendwas brauchen, dann ist das einfach schnell dazu gebaut. Also wenn wir über Etlaschen oder andere gehen würden, dann müssten wir da immer schauen, wie wir es organisieren.

SPEAKER_00 33:32

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-Service-Companys, 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 schmaß geschneidet 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, gehen da den Bach holen. Oder zumindest, es sieht so aus, als würde es in eine Richtung gehen, in der diese Geschäftsmodelle sehr massiv gefährdet sind.

SPEAKER_01 34:28

Ja, richtig. Wir haben ja als SARS-Company die gleiche Fragestellung nach vorne. Also 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.

SPEAKER_00 34:58

Aber vielleicht kannst du mir also 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 ein 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 erstmal recht einfach, das Thema ein kleines CRM für mich zu machen, das Thema richtig, 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 gerade 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 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.

SPEAKER_01 36:24

Und das mache ich gerne. Also, eine Software zu bauen, die schnell funktioniert, die bei 80% 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 weiter gewartet 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 magst, 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 Weitermitwachsen der Datenstrukturen, dieses Weitermitwachsen des Systems, das ist etwas, um das du dich dann aktiv kümmern musst. Das heißt, du machst dir da 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, indem 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 es, also 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, das ist auch so eine charakteristische Eigenschaft von uns, dass wir in spezifischen Branchen unterwegs sind, dass wir dieses Wissen aus den Branchen haben. Also 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 Eltphilharmonie, 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.

SPEAKER_00 39:14

Ich teile deine Einschätzung. Ein bisschen ist im Widerspruch natürlich zu dem, was ihr, ihr baut ja selber in Jira nach, oder indirekt. Eigentlich müsstest du dann ja auch sagen, naja, ist das denn jetzt so sinnvoll, weil später brauchen wir ja, 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 einer 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.

SPEAKER_01 40:21

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 immer möglichst, also 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 unserem 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 Kernprodukt 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, erst dein eigenes Brot. Und das als erstes.

SPEAKER_00 41:22

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 SARS-Umfeld. Siehst du eine allgemeine, oder wie ist denn dein allgemeiner Blick auf das SARS-Thema? Wenn ich mir die Börsenkurse anschaue, da ist da sehr viel Ungewissheit, die gerade fürs eingepreist wird. Sobald es nochmal neue Entwicklungen geht, gehen die Kurse von SAP und Salesforce und sowas gehen halt in den Keller. Was ein Zeichen für die steigende Unsicherheit ist. Wir werden mit Sicherheit keine SARS-Apokalypse sehen, dass jetzt alle SARS-Unternehmen der Verdammnis anheimfallen. Auf der anderen Seite hat es ja schon disruptiven Charakter. Also wie ordnest du das so global galaktisch ein?

SPEAKER_01 42:18

Also die Unternehmen, die genau ein Problem lösen und dafür eine SARS-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, aber heute hat es keinen Wert mehr. Es tut mir leid, das so aussprechen zu müssen, aber es ist so. Heute hat die Fähigkeit gewonnen, dass man Businessprozesse, 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-Schnellen hat und X Systeme miteinander verbinden muss. Man muss eine logische Abfolge have for Geschäftsprozesse, um die für die Kunden dann so abzubilden und zugänglich zu haben, dass sie gut damit arbeiten können. Und das eben bei einem logischen Anfang bis hin zu einem logischen End des Prozesses. Dann, when man das upbilden kann, has man a good asset. This is my jetzige Einschätzung. This can sein, that I in 12 months etwas ganz and this is aufbauend of dem Business, das wir heute haben. Meine Meinung. Wie gesagt, je einfacher die Anwendung ist, umso eher ersetzbar wird sie.

SPEAKER_00 43:41

Wie gehst du allgemein mit Unsicherheit bei dir im Team und wenn sich so fundamental etwas verändert? Du hast jetzt ein Beispiel genannt, mit einem, dem das sehr zugutekommt, diese neue Art zu arbeiten. Es gibt aber für Leiche auch den anderen Mitarbeiter, der sich sehr stark darüber definiert hat, sehr tiefes Detailwissen über Implementieren. Übereffizienz und so weiter so, sich damit ja 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?

SPEAKER_01 44:23

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 Tupus auch im Team. Und 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 rauszuarbeiten, wo in Zukunft ihre Schwerpunkte liegen können. Das Thema Personalentwicklung ist für 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 Back-Office macht, die auf einmal hört, okay, ein Teil ihrer Tätigkeiten wird automatisiert, da muss ich mit ihr einfach drü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 weiterentwickle. Und wir schauen als Unternehmen insgesamt darauf, dass wir die Rollen der Menschen im Unternehmen weiterentwickeln in die Zukunft und die in der Universität.

SPEAKER_00 46:04

Wie entwickelt ihr die konkret weiter? Also ich verstehe klar, es ist ein bisschen eine Gratwanderung zwischen Psychologie, gut zureden, Lösungen oder auch 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?

SPEAKER_01 46:26

Also einmal sind es fachliche Trainings, tatsächlich den Umgang mit Cloud 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 und soweit uns es heute möglich ist, das abzuschätzen, wo sich das hin entwickeln wird. Und die gibt es für jeden nachzulesen im Intranet.

SPEAKER_00 47:39

Du hast auch eben noch ein Thema angesprochen, was man in mehrere Richtungen interpretieren kann. Du hast angedeutet auch, Softwareentwicklung ist oder Code schreiben ist kein Engpass mehr, hast du sinngemäß gesagt. Das ist 100% richtig. Es gibt sehr viele, die dann gerade das weiterspinnen und dann sagen, Software Engineering steckt in einer Krise. Und an dem Punkt, ich weiß nicht, wie du das siehst, an dem Punkt würde ich einhaken, aber sagen, das sehe ich nicht so. Ganz im Gegenteil, ich sage, glaube ich, Software Engineering wird gerade die nächste neue Hypephase auf sie zusteuern. Was in der Krise ist, ist die Rolle des Software Engineers, weil der sich jetzt fundamental verändern muss, anpassen muss an diese 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. Bist du da, siehst du das ähnlich oder wo würdest du da nochmal einen anderen Ansatz in den Ansatz nehmen?

SPEAKER_01 48:51

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, who auch immer, started and geschmiedet had and then at the toll geschmiedetes Metallteil gefertigt had. And then call the Industrialisier mit den Werkhallen, with the Fabriken, with the Machines, die then finer ausgearbeitet wurden. And was es heute braucht, ist nicht der Schmied, der da steht anders Werkstück hat, sondern es ist jemand, der eine Maschine bedient, der 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. And 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 reibt. Aber am Ende des Tages ist das Stück Software, das rauskommt, ist das relevante Ergebnis. Und da braucht es Menschen, die das, die dafür sorgen, dass das rauskommt.

SPEAKER_00 50:37

Das ist richtig. Bestehst du zu dem Begriff der Softwarefabrik? Das wäre ja etwas, ich habe das durchaus schon im eigenen Kundenumfeld schon erlebt, dass diese Begrifflichkeit verwendet wird, auch um das zu beschreiben, was Agentic AI zukünftig sein wird. Das geht ja eine ähnliche Richtung, was du beschrieben hast.

SPEAKER_01 50:56

Ich habe mich mit dem Begriff gedanklich noch nicht auseinandergesetzt. Ich habe jetzt also jetzt keine Meinung. Softwarefabrik. Ja, so ein bisschen. Oder lass mich das da mal anders formulieren.

SPEAKER_00 51:13

Also, 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 14 Monaten, äh, 12 bis 24 Monaten?

SPEAKER_01 51:38

Ja, wir werden sehr viele Automatisierungen erleben, und zwar komplexe Automatisierungen, also einfache 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 Gen GI 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 Agenic. Und dass wir dann an der Stelle sehr viele Möglichkeiten haben werden, um auch da wieder als Konsumenten zu automatisieren und unser eigenes, unseren eigenen Alltag effizienter zu gestalten.

SPEAKER_00 52:37

Was unterschätzen aktuell die meisten CTOs beim Thema Agentic AI?

SPEAKER_01 52:42

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 noch ein kleines Spielfältchen ist, irgendwas auf, irgendeine Tür offen, 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 ist, das zu erkunden, das ist eigentlich heute die Hauptaufgabe eines CTOs.

SPEAKER_00 53:36

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.

SPEAKER_01 53:49

Das ist neu für mich.

SPEAKER_00 53:50

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?

SPEAKER_01 54:03

Sie ist kein Erheilmittel. Also, wer sie als Erheilmittel versteht, wird eine Enttäuschung erleben.

SPEAKER_00 54:10

Ein Tool, das du, ohne dass du aktuell nicht mehr arbeiten kannst, willst? Jetzt gerade Claude Code. 100 Prozent. Wobei ich da auch jetzt gehört habe, Codex muss gerade auch nochmal einen Schritt nach vorne gemacht haben. Aber da darf man auch sich 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?

SPEAKER_01 54:41

Unterschätzt.

SPEAKER_00 54:42

Sehr gut. Gehe ich auch mit, ehrlich gesagt. Auch wenn noch viele noch gar nicht das ausgenutzt haben, was aktuell schon möglich ist.

SPEAKER_01 54:51

Genau. Und ich glaube einfach eben immer noch an das, was ich gerade vorhin gesagt habe, es gehen jeden Tag irgendwo neue Türchen und Fensterchen auf.

SPEAKER_00 54:59

Sehr richtig. Was ist denn der eine Skill, den Entwickler jetzt lernen müssen?

SPEAKER_01 55:04

Das Zusammenspiel von Agenten, das zu beherrschen, die Orchestration von Agenten. Das ist der Skill der heute Entwicklung. Gefordert wird und in Zukunft notwendig sein wird.

SPEAKER_00 55:15

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

SPEAKER_01 55:41

Also in Bezug auf Lehrpläne kann ich und möchte ich da gar keine Proponzen 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 Mitstudenten, mit denen er da regelmäßig sich trifft, dass die Projekte damit gestemmt haben und die studieren alle keine 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.

SPEAKER_00 56:29

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?

SPEAKER_01 56:36

Die 20 von früher werden bald so viel liefern wie 100.

SPEAKER_00 56:40

Oder so, ja. Also ja.

SPEAKER_01 56:43

Ja. Ja.

SPEAKER_00 56:45

Ja, genau.

SPEAKER_01 56:46

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 Effizienz, die Steigerung der Effizienz im Vordergrund steht.

SPEAKER_00 56:57

Das ist richtig. Wobei ich auch nicht da, 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 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.

SPEAKER_01 57:36

Das, genau. Das wird die Zukunft zeigen.

SPEAKER_00 57:39

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 da 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. Hat sich seitdem einiges bei euch getan. Ich glaube, ihr seid, wenn ihr vor acht Monaten gestartet seid, wirklich sehr, sehr weite 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 dann stehen werden. Dann kommst du nochmal und erzählst, wie es weiterging.

SPEAKER_01 58:27

Sehr gerne. Danke für die Einladung und unser tolles Gespräch.

SPEAKER_00 58:30

Sehr schön. Michael, mach's gut. Ciao, ciao.

SPEAKER_01 58:33

Ciao, Philipp.