Becoming CTO Secrets
Becoming CTO Secrets ist der Podcast für ambitionierte Tech-Leader, angehende und aktive CTOs und Unternehmer, die Technologie nicht nur verwalten, sondern strategisch wirksam einsetzen wollen.
Hosted von Philipp Deutscher, langjähriger CTO, Coach, Experte und Sparringspartner für Führungskräfte mit knapp 20 Jahren Erfahrung im Aufbau, in der Skalierung und der Führung internationaler Tech-Organisationen.
In diesem Podcast geht es nicht um Buzzwords oder Karriere-Romantik, sondern um die Realität der CTO-Rolle:
Verantwortung, Entscheidungsdilemmata, Macht, Einfluss, Technologie und die oft unbequemen Wahrheiten dazwischen.
Jede Episode beleuchtet zentrale Fragen moderner CTO-Führung:
- Wie entsteht echte Wirksamkeit im C-Level?
- Wie baust du leistungsfähige Engineering-Organisationen?
- Wie triffst du gute Entscheidungen unter Unsicherheit?
- Wie verbindest du technische Exzellenz mit Business-Impact?
- Wie navigierst du Skalierung, Kultur, Konflikte und politische Spannungsfelder?
Neben Solo-Episoden erwarten dich offene, ehrliche Gespräche mit erfahrenen CTOs, Tech-Executives und Entscheidern aus unterschiedlichsten Branchen mit konkreten Learnings, Denkmodellen und Perspektiven, die sich direkt auf deine eigene Rolle übertragen lassen.
Becoming CTO Secrets richtet sich an Menschen, die mehr wollen als Titel.
An Tech-Leader, die Verantwortung übernehmen, Wirkung entfalten und Technologie als strategischen Hebel verstehen.
Becoming CTO Secrets
"Der Mensch wird keinen Code mehr schreiben" - Was Agentic AI wirklich verändert
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
AI Agents sind nicht mehr nur Hype. Sie verändern bereits, wie Unternehmen arbeiten, wie Software entwickelt wird und welche Rolle CTOs künftig einnehmen müssen.
In dieser Folge von Becoming CTO Secrets ist Gregor Blichmann zurück im Podcast. Gregor ist CTO und CPO von elevait und beschäftigt sich täglich damit, wie Unternehmen AI nicht nur ausprobieren, sondern wirklich in Prozesse, Produkte und Organisationen integrieren.
Gemeinsam sprechen Philipp und Gregor über die Frage, was Agentic AI wirklich bedeutet – und wo die Grenze zwischen Chatbot, Workflow-Automation und echtem AI Agent verläuft.
Es geht um:
- warum viele Unternehmen bei Agentic AI zwischen Euphorie und Überforderung stehen
- was ein AI Agent tatsächlich können muss
- warum Guardrails, Datenqualität und Kontext entscheidend sind
- wie Agentic AI die Softwareentwicklung verändert
- warum Entwickler künftig weniger Code schreiben, aber mehr Verantwortung für Spezifikation, Qualität und Ergebnis tragen
- wie Unternehmen den ROI von AI Agents messen können
- warum Kosten, Tokenverbrauch und Governance massiv unterschätzt werden
- und weshalb „abwarten“ für Entscheider gerade der gefährlichste Fehler sein könnte
Eine Folge über Agentic AI, CTO-Verantwortung, Softwareentwicklung, Organisation, Leadership und die Frage, wie Unternehmen in einer Welt bestehen, in der AI nicht mehr nur Antworten gibt – sondern Arbeit übernimmt.
🚀 Becoming CTO Secrets ist ein Podcast von Philipp Deutscher Consulting
→ www.deutscherconsulting.com
📘 Whitepaper „Entwickler Heute, CTO Morgen“
→ whitepaper.becomingctosecrets.com
📑 CTO Report 2025: Archetypen, Technologien, Zukunftsszenarien
→ ctoreport.becomingctosecrets.com
🤝 Becoming CTO Community
→ deutscherconsulting.com/becoming-cto-community
🎯 CTO Coaching Programm
→ deutscherconsulting.com/cto-coaching
💬 Vernetze dich mit Philipp auf LinkedIn
→ linkedin.com/in/philippdeutscher
Hallo und herzlich willkommen zu Becoming CTO Secrets, dem Podcast von CTOs, für CTOs und all diejenigen, die es noch werden wollen. Ich bin Philipp Deutscher, externer CTO, CTO-Coach und der Gründer der Becoming CTO Community. Heute ist Gregor Blichmann zurück bei uns im Podcast. Gregor ist der CTO und der CPO von Elevate und beschäftigt sich täglich mit der Frage, wie Unternehmen AI nicht nur ausprobieren, sondern wirklich tatsächlich in Prozesse und Produkte integrieren. Darum dreht sich das Unternehmen. In dieser Folge heute sprechen wir natürlich über Agentic AI, über Hype, über Realität und natürlich auch darüber, warum die eigentliche Herausforderung nicht die Technologie ist, sondern die Organisation dahinter. Das mag für den ein oder anderen überraschend sein. Gregor, herzlich willkommen zurück. Hallo Philipp, schön, bitte hier zu sein. Ja, genau, sehr gerne. Es freut mich auch sehr. Du hast mir mal geschrieben vor ein paar Wochen, dass du gerade tief im Thema Agentic AI steckst. Und dass sich das ja gut anbieten würden, eine zweite Session dazu zu machen. Tatsächlich ist das ja ein immer wiederkehrendes Thema in den letzten Folgen gewesen, aber ich glaube trotzdem, dass das sehr viel Sinn macht, dass wir zwei darüber sprechen. Und das ist auch gerade der perfekte Moment, weil viele Unternehmen gerade zwischen Euphorie und aber auch Überforderung hängen. Und ja, deshalb vielleicht gerade die Frage an dich oder an euch, wo steht ihr denn gerade beim Thema Agentic AI?
SPEAKER_00Das hast du gut eingeleitet, wenn ich darf, wir hatten auch vor zwei Wochen so ein Tech-Lead-Roundtable-Event, wo ich dabei war. Und man sieht es an allen Enden, dass viele Leute, glaube ich, genau an dem gleichen Funkrad stehen. Man hat so ein bisschen diesen Hype jetzt mitgenommen im Sinne von, man muss was tun, aber man ist ein Stück weit überfordert, was ist jetzt zu tun. Und man sieht an vielen Stellen und mit vielen Gesprächen, dass eigentlich viele Leute an der gleichen Stelle gerade sind. Und wie du es gerade sagst, macht total Sinn, sich mehr auszutauschen und Erfahrung zu teilen. Auch wir, wir sind ja als Natur ein Automatisierungsunternehmen, das Software baut. Das heißt, KI ist schon länger bei uns ein Thema im Unternehmen. Aber auch wir haben natürlich jetzt das Momentum, das über uns hereinprasselt, dass Agenten alles revolutionieren, man alles neu denken muss. Und wir sind gerade an dem Punkt, dass wir es geschafft haben, im Unternehmen selbst uns zu fragen, wie können wir als Organisation Agenten besser einsetzen und KI, aber eben auch, wie sind die Wechselwirkungen mit unserem Produkt. Und das sind so zwei Ebenen, mit deren wir uns beschäftigen und gerade die Herausforderungen Richtung, wie setzen wir eine Organisation ein, sind schon groß oder sind auf alle Fälle keine kleinen Herausforderungen, die es jetzt gemeinschaftlich als Organisation zu bewältigen gilt.
SPEAKER_01Ja, genau. Wir hatten, glaube ich, du warst in Folge 42, warst du bei uns zu Gast, dass jetzt wir, wird die Folge 57, da ist eine ganze Menge passiert in der Zwischenzeit. In der ersten Folge haben wir auch schon darüber gesprochen, dass KI gleichzeitig überschätzt und unterschätzt wird. Hat sich denn an dieser Einschätzung durch die letzten Entwicklungen eher verstärkt oder hat sich damit daran an dieser Einschätzung irgendwas drastisch verändert?
SPEAKER_00Ich glaube, das ist eine Frage der Perspektive und der Rolle im Unternehmen. Ich glaube schon, also mein Netzwerk zeigt zu wissen, dass ein klares Bild entstanden ist, was man wirklich erwarten kann. Ich glaube nicht, dass die Überschätzung komplett hinfurt ist, aber ich glaube, es gab jetzt schon mehr Leute, die sich aktiver damit beschäftigt haben, was kann es wirklich für meine Organisation, für mein Umfeld leisten und jetzt viele Leute eben an dem Wie kämpfen. Also klar ist, wir wollen es tun, wir haben vielleicht ein Gefühl dafür, wo es uns helfen kann, aber wie können wir jetzt wirklich ins Doing kommen, wie können wir das in die Organisation bringen? Das sind vielleicht jetzt die Themen, wie du es richtig gesagt hast, die in den letzten Wochen, Monaten sich jetzt noch mehr schärfen oder rausgebildet haben.
SPEAKER_01Ja, wie nimmst du das denn wahr? Also ich sehe viele Unternehmen, die haben gerade das Gefühl, ja, wir müssen irgendwas mit Agenda KI machen. Oder was glaubst du, dass es immer berechtigt? Ist da auch ganz viel Aktionismus dabei? Ist da Panik dabei? Wie nimmst du das aus deiner Warte wahr?
SPEAKER_00Also natürlich ist es ein bisschen Follow the Hype immer noch. Also natürlich kommt man an diesem Thema nicht vorbei. Und ich glaube schon, dass es auf Management-Ebene oder gerade in größeren Konzernen eher so ein Label ist, was man sich gibt und gesagt wird, wir machen jetzt auch Agent DKI und dann wird viel Geld in die Hand genommen, um irgendwie eine Plattform zu launchen, wo man Agenten laufen lassen kann. Oder es wird irgendwie eine große Lizenz gekauft, um einen der bekannten Modelle zu nutzen, ohne wirklich vielleicht am Ende ein klares Konzept zu haben, wo nutzen wir das, mit welchem Mehrwert, wie messen wir den Erfolg und wie bringen wir es denn wirklich in die Fläche? Also wie bringen wir die Leute dazu, es wirklich gut zu nutzen? Da gibt es einige Herausforderungen, die wir bestimmt dann noch streifen werden.
SPEAKER_01Ja, aber dann lass uns das doch mal sauber einordnen. Wann ist denn für dich ein System wirklich ein AI-Agent? Und wann ist es am Ende des Tages nur ein besserer Chatbot? Wo ist da die Trennschärfe? Was denkst du?
SPEAKER_00Ich habe das letzte Wort oder die letzte Phrase, die du genommen hast, genau, glaube ich, der Ansatz. Wir hatten alle diesen Chat-GBT-Moment, nenne ich ihn jetzt mal, wo wir alle verstanden haben, was solche großen Sprachmodelle in der Lage sind für uns zu tun. Und viele Leute haben angefangen, quasi eine Unterstützung für sich selber daran zu finden, dass sie in einer Chatbasierten Interaktion, E-Mail-Texte, Recherchearbeiten und so weiter für sich quasi als Ergebnis bekommen konnten. Und ergänzen ist als meiner Sicht der nächste Schritt, die nicht unbedingt, also das heißt nicht, dass wir eine neue Technologie haben, sondern es werden auch Sprachmodelle im Zentrum, stehen auch im Zentrum, aber wir haben eben die Möglichkeit, wirklich wirksam zu sein, sondern wirklich E-Mails abzuschicken, wirklich bestimmte Dokumente zu bearbeiten, bestimmte Systeme einen Auslöser zu geben, etwas zu tun. Das heißt, der Wandel zum Agentischen bedeutet einfach wirklich, in die Handlung zu kommen und das eben idealerweise autonom. Das heißt, wir können einem solchen Agenten eine Aufgabe geben, die ja einmalig oder wiederkehrend wirklich in einem Zielsystem, in einer Menge von Zielsystemen für mich ausführt und im besten Fall mit bestimmten Guardrails und Anweisungen eben vollkommen autonom. Und das ist jetzt der Schritt vom eigentlichen Chatbot zu, wirklich Arbeit, sage ich mal, autonom abgeben.
SPEAKER_01Wo verläuft denn für dich da die Grenze, gerade zwischen so Assistant, dem Thema Workflow Automation und dem eigentlichen Agenten?
SPEAKER_00Ich glaube, die Grenze kann, aber das ist eine sehr philosophische Frage, glaube ich, am Ende. Und da gibt es verschiedene Perspektiven. Kann man ziehen in dem Sinne von wie viel ist bekannt? Es gab früher RPA-Lösungen, es gibt früher Automatisierungslösungen, die regelbasiert waren. Da musste man natürlich die ganzen Rahmenbedingungen, die APIs, die man genau ansprechen möchte, die Daten und so weiter ganz genau vorgeben. Und die Grenze zum Agentischen ist aus meiner Sicht, dass man diesen Weg zum Ziel nicht mehr so hart vorgeben muss, sondern dass man quasi dem System den Kontext liefert, was es braucht für seine Entscheidung, wie es zum Ergebnis kommt. Und quasi mehr Freiheiten den Agenten gibt, quasi welche Systeme, welche APIs, welche Dokumente spielen jetzt welche Rolle für meine Entscheidung und wie setze ich das Ganze dann um.
SPEAKER_01Wie ist das bei dir? Wann musst du sagen oder was muss ein Agent können, damit du sagst, dass es wirklich ein Agent, dass es nicht nur reine Workflow-Automation, dass es nicht nur irgendwie eine UI und da ist ein LLM da hinten dran, sondern das hier ist wirklich etwas Neues, etwas, was auch Dinge auf eine neue Art und Weise tut?
SPEAKER_00Ich glaube, wenn ich, wenn man eine komplexe Aufgabe, die mehrere Schritte typischerweise beinhaltet, die ein Mensch oder zum Teil eben eine LM-Vergangen gemacht hat, komplett autonom Ende zu Ende arbeiten kann. Und diese Aufgabe im Zweifelsfall in verschiedenen Ausprägungen, ohne dass man sie vorgegeben hat, trotzdem bewerkstelligen kann. Also wenn sich die Situation ändert, der Kontext ändert, der Agent trotzdem in der Lage ist, darauf zu reagieren und mir ein Ergebnis liefern kann, dann glaube ich.
SPEAKER_01Muss ein Agent dann dann autonom handeln können? Ist das für Grundvoraussetzung dafür?
SPEAKER_00Nee, das ist nicht notwendigerweise. Also ich glaube, es gibt auch, also das ist unser täglich Brotfairerweise. Es gibt sehr viele Situationen, gerade wenn wir ein bisschen wieder in den B2B-Bereich gucken, Software-Bereich gucken, Automatisierungsbereich gucken, gibt es durch Compliance-Gründe, Geschäftsgebarengründe, Sicherheiten, die man einbauen muss, damit der Mensch wirklich bestätigt, dass das richtig ist, dass das so verwendet werden kann, dass das ausgelöst werden kann. Also es muss nicht notwendigerweise komplette Autonomie Ende zu Ende sein, aber eben schon ein gewisser Grad von Automatisierung muss in diesem ganzen Kontext irgendeine Rolle spielen.
SPEAKER_01Redest du dann auch, wenn du intern darüber sprichst, auch von Guardrails? Oder wie bezeichnet ihr das? Weil ich meine, die Autonomie ist ja kein binärer Zustand. Du kannst das ja auch auf einer Skala von 1 bis 100 kannst du sagen, wie autonom ist man denn gerade? Und natürlich brauchst du halt irgendwelche Grenzen oder Rahmenbedingungen. Ich meine, wir handeln ja auch nicht volautonom, wenn wir im Unternehmen unsere Rollen einnehmen. Wir haben ja auch unsere Guardrails und Dinge, die wir tun dürfen und nicht dürfen. Wie machst du das im Unternehmen, wenn es um Agenten geht?
SPEAKER_00Also Guardrails ist da definitiv ein Begriff, der da immer wieder fällt und zu klären ist. Fairerweise sind wir als Unternehmen auch gerade an dem Punkt zu sagen, wie groß sollte die Freiheit sein, wie groß sollten die Sicherheitsmechanismen, die Guardrails sein und die gibt es ja auf mehreren Ebenen, die gibt es auf Technologieebene, welche Technologien sind erlaubt und nicht erlaubt, die gibt es auf Datenebene, welche Daten dürfen benutzt werden, welche nicht, die gibt es auf Use Case-Ebene, welche Prozesse dürfen über solche Systeme betreut werden und welche nicht. Da sind wir auch gerade ganz intensiv als Team, als Gruppe im Austausch, wie wir das leben wollen oder wie wir uns dahin entwickeln. Weil das natürlich ein interessantes Spannungsfeld ist zwischen Freiheit und dementsprechend Innovation und neuen Ideen und Compliance und Regulatorik, die es zu beachten gilt.
SPEAKER_01Und wie nutzt ihr Agent TKI konkret? Geht es darum, Agent TI im Rahmen eurer Deals oder eures Produkts, was ihr den Kunden anbietet, einzusetzen? Oder geht es auch darum, wie ihr Agent TKI im Rahmen der Entwicklungsprozesse einsetzt?
SPEAKER_00Beides. Also natürlich müssen wir uns als Automatisierungsfirma, die schon, wie gesagt, vor fünf Jahren KI-Komponenten eingesetzt hat, der Frage stellen, wie disruptiv sind Agenten für unser Geschäftsmodell, für unser Produkt. Und da muss es ein Bestandteil in der Zukunft sein, auch agentische Bausteine eben damit im Produkt zu haben. Aber der größere Teil tatsächlich, glaube ich, gerade die Frage, wie wir das als Organisation nutzen. Und da finde ich, ist natürlich Software Engineering das Paradebeispiel, wo wir über alle reden und auch durch die Natur der Modelle sehr stark daran sind. Aber ich glaube, es ist trotzdem auch genauso wichtig. Zum Beispiel meine Rolle nutze ich ganz stark so einen persönlichen Assistant, der eben mit ganz viel Wissen aus dem Org-Chart, aus den Rollen, aus den Mitarbeitenden, aus Gesprächen, mir Empfehlungen, mir Zusammenfassungen, mir irgendwie Dinge, Strategien ausarbeiten kann, die ganz abseits sind vom klassischen Software-Engineering-Workflow. Und das sind so quasi, wir versuchen gerade, wir nennen das, sag ich mal, Leuchtturm-Projekte im Unternehmen zu etablieren, wo wir mal mit kleinen Gruppen, zwei bis drei Leuten ganz abgeschlossene Use Cases voll agentisch denken, um die dann quasi wieder als Leuchtturmbeispiel in die Firma zu bringen und sagen, hey, das hat gut funktioniert, aber auch ganz genau sozusagen, das hat eben nicht funktioniert oder das ist ein Schmerz, der dabei entsteht.
SPEAKER_01Aber da sind wir ja gerade wieder bei dieser Einordnung, die ich am Anfang versucht habe zu machen. Wenn du jetzt von Assistant redest, also für mich ist der Assistant, wenn ich die, auch selbst wenn ich da einen kompletten Kontext, einen Rack hintendran habe, die komplette Unternehmensdokumentation und mit einem Assistant darauf zugreifen kann, ist das für mich noch nicht Agentic? Oder wie siehst du das?
SPEAKER_00Philosophisch gute Frage. Also vielleicht würde der eine sagen, es ist noch nicht kein komplettes Agenk im Sinne von, ich habe eine Orchestrierung von fünf Agenten, die autonom untereinander Aufgaben austauschen. Andererseits ist es ein Stück weit schon nicht mehr dieses Chatten. Man sagt jetzt, also es gibt ja ganz kleine Aufgaben, die waren jetzt die Woche erst ja präsent bei mir. Manchmal ist es super gut, in einer physischen Zusammensitzung, in einem Meeting mit Sticky-Notes an einem Whiteboard zu arbeiten. Aber niemand hat Lust, die zu digitalisieren und so weiter. Was macht man heute? Man macht ein Foto von den Whiteboards, gibt es einem Agenten und sagt, hier bauen wir mal, wir nutzen uns Figjam, bauen wir mal ein digmetales Fig Jam-Board raus, schreibt mir eine Zusammenfassung und bereit eine Nachricht vor ans Team, die das Ganze nochmal transparent mitgibt, was wir gemacht haben. Das ist auf alle Fälle über Chatten, aber vielleicht noch nicht dieses vollautonome Agenten-Setup, was man vielleicht im Kopf hat.
SPEAKER_01Nutzt ihr an manchen Stellen in eurem Software Development Lifecycle schon Agentic AI, also tatsächlich auch Agents, die im Rahmen von bestimmten Guardrails bestimmte Dinge aktiv tun dürfen und durch Events getriggert werden? Also es muss ja noch keine Armada oder Armee von orchestrierten Agenten sein, aber vielleicht in einem bestimmten Workflow, abhängig von bestimmten Ereignissen, die eintreten, wenn ein Ticket einen bestimmten Status erreicht oder ein Review oder Pull-Request fehlschlägt, dann macht ihr sowas schon?
SPEAKER_00Also wir sind, also wo wir begonnen haben, vielleicht ein bisschen historisch gesehen, war wirklich der Klassiker, die entwickelnden Personen im Unternehmen zu ermächtigen, mit Hilfe von KI oder eben agentischen Systemen schneller Code zu produzieren oder schneller irgendwie Features zu bauen. Was dann natürlicherweise passiert ist, dass du viel, viel mehr Pull-Requests oder Change-Requests in deinen Repos hast. Und dann, wie vielleicht auch in vielen Vorgänger-Podcasts beschrieben, wird eben die Rolle vom rein Entwickelnden zum eher reviewenden Mitglied des Teams dann. Und auch wir haben dann von der Herausforderung gestanden, und stehen sie nach wie vor, dass, wie kommst du mit dieser Menge von Veränderungsrequests klar. Und da gucken wir gerade rein, wie kann dort ein Agent autonom vielleicht Pull-Requests merchen oder eben die ganzen Quality-Checks, die wir haben, Tests und so weiter ausführen, um eine Entscheidung zu treffen, das kann gemerged werden oder nicht. Auch da ist die Idee ganz klein, mit sehr punktuellen Feature-Blöcken Leuchtturmprojekte zu machen, um dann zu gucken, was waren die Learnings, um es dann breiter werden zu lassen.
SPEAKER_01Würdest du es heute wieder in der Reihenfolge einführen? Also zuerst so lass uns mal ganz viel Code schreiben und dann, ah, scheiße, jetzt müssen wir ja wieder gucken, wie wir den ganz vielen Code reviewen. Also die Frage ist tatsächlich relevant, weil die allermeisten beginnen mit der Creation und ich halte zuerst die Absicherung zu machen hinten raus, dass ich mir später gar nicht erst darüber Gedanken machen muss, den ganzen Code auch zu reviewen erstmal, sondern vielleicht zuerst die Arbeit reinzustecken in, naja, wie baue ich denn eine so verlässliche Agentic AI-Augmented Review-Strategie auf, dass ich erst gar nicht in diese Situation komme. Und wenn ich da die Sicherheit habe, dann fange ich an, Features zu entwickeln. Klingt natürlich so auf dem Reißpräch, vielleicht so, ja, macht schon Sinn, das ist so zu machen. Aber vielleicht ist es auch unbedingt notwendig, das zuerst mit der Creation anzufangen, weil du so die Leute halt besser mitnehmen kannst. Aber wie, hattet ihr einen Grund, warum ihr in diese Richtung gegangen seid und würdest du es heute nochmal genauso machen?
SPEAKER_00Also du hast es richtig angerissen. Ich glaube, da gibt es zwei Antworten. Eine Antwort ist, wenn wir das heute nochmal starten müssten und noch gar nichts machen würden, würden wir es anders denken, glaube ich. Dann würde man es mehr, wie du sagst, schon Ende zu Ende denken. Also wie kann wirklich ein Feature-Autonom am Ende auch wirklich deployed werden, sage ich jetzt mal ganz kühn. Aber was man betrachten muss, du hast das Wort genannt, Vertrauen. Ich glaube, das ist ein wichtiges Thema, wenn man das in eine Unternehmung einführt. Und selbst wenn das sehr junge, sehr dynamische, softwareentwickelnde Person sind, gibt es eine gewisse Skepsis. Und die Rolle dieser Personen wird sich ändern. Und das muss man, glaube ich, auch respektieren, dass man sie Stück für Stück ranführt. Und ein zweiter Punkt ist natürlich, als wir damit begonnen haben, war die Mächtigkeit dieser Modelle noch ein bisschen geringer. Also wir machen das ja schon seit vielleicht jetzt einem Jahr, anderthalb. Und da war es wirklich erstmal ein Assistant im Coding. Da war es so ein Tab Completion, ich schreibe jetzt mal den Doc-String und lasse mir die Funktionen generieren und guck mal, was rauskommt. Also war noch viel mehr wirklich Review im Klein-Klein notwendig und dann haben sich eben die Entwicklungen entwickelt, wie sie sich entwickelt haben. Und mittlerweile ist natürlich klar, dass die Fähigkeiten, Mächtigkeiten der Modelle viel größer geworden sind. Aber wenn man heute eben anfangen würde, würde ich, glaube ich, eher deinen Weg gehen.
SPEAKER_01Ja, ich glaube auch, mittlerweile hat sich in der gesamten Software oder nicht überall, aber in ganz vielen Bereichen hat sich was getan. Wenn wir vor einem halben Jahr noch, also ich betrachte das immer auf den verschiedenen Leveln an Autonomie und Automatisierungsgrad. Von Layer 1 bist du noch bei komplett manueller Softwareentwicklung und Layer 5 wäre dann das Thema einer vollautonomen Softwarefabrik oder einem vollautonomen Softwareprozess. So, da waren wir vor einem halben Jahr vielleicht auf Level 2, also wo genau diese Code-Completion stattgefunden hat innerhalb einer Idee. Mittlerweile sind viele Unternehmen ja schon auf Level 3 unterwegs oder auf dem Weg dahin. Aber ja, über das Thema Orchestrierung und mehrere Agenten parallel laufen zu lassen oder abhängig voneinander Dinge tun zu lassen, da tun sich einige noch schwer. Hast du eine Idee, warum das so ist? Ist das einfach eine Frage von, man ist noch nicht so weit und man macht sich jetzt erst Gedanken um das Thema Orchestrierung oder ist das auch der Moment, wie beim autonomen Fahren, dass man ewig lang einem Level 5, dem vollautomatisierten Fahren hinterherrennt und gefühlt seit zehn Jahren dem nicht so wirklich näher kommt?
SPEAKER_00Ich glaube, das ist eine Frage der Verteilung, also das muss man über die Verteilung, glaube ich, sehen. Also es ist vielleicht eine Art Gauss-Verteilung, wo man sagt, es gibt, glaube ich, die Spitze der Leute, die ganz früh Early Adapter sind, die ganz stark an das Thema glauben und die das Ganze auch pushen, auch wenn es vielleicht technologisch noch nicht ganz ausgereift ist oder es nach Hürden gibt. Und dann haben wir aber, glaube ich, so eine Verteilung nach unten, wo es immer noch Leute gibt, die jetzt gerade so ihre ersten Schritte machen. Und ich glaube, da ist das Thema Vertrauen, Governance und Compliance ein großes Thema, gerade im Unternehmenskontext. Wie schafft man es in gegebenen Strukturen? Also ich kenne auch Corporate-Strukturen, die eben einfach Zyklen von mehreren Wochen, Monaten haben, wenn es darum geht, man ein neues Tools zu bekommen oder ein neues Modell freizuschalten und so weiter. Und da sind, glaube ich, Leute froh, überhaupt erstmal den Zugang zu den LLM zu bekommen. Und da braucht es dann wahrscheinlich starke Führungskräfte oder visionäre Führungskräfte, die in solchen Strukturen dann sagen, jetzt denken wir ein bisschen disruptiver. Und wenn da braucht es, glaube ich, da muss man ein bisschen Geduld haben, glaube ich, dass sich die Entwicklung über die Zeit wird sich das alles anheben, aber jetzt gerade ist es, glaube ich, in der Fläche noch nicht auf dem Level, dass alle LLM-Experten oder alle Agene-Experten schon sind, sage ich mal.
SPEAKER_01Wie nimmst du das bei euch in der Organisation wahr? Also ihr seid ja auch aufgrund des Produktes, das ihr baut oder der Dienstleistungen oder der Services, die ihr anbietet, seid ihr, habt ihr eine hohe Affinität zum Thema AI. Ist das dann auch in der Entwicklung so? Das heißt, wenn du jetzt sagst, wir möchten, wir, wir sollen, wir müssen weiter Richtung AI und Agentic AI bewegen, zieht die gesamte Mannschaft mit oder bremsen sie dann doch, weil sie sagen, ach, das müssen wir alles ja erstmal selber machen. Wie hast du das erlebt?
SPEAKER_00Es gibt beides. Es ist absolut beides und das kann man offen reflektieren. Wir sind, also nach meiner Einschätzung, wie du es gut sagst, wir sind eine sehr KI-affine Firma. Wir arbeiten täglich damit und nichtsdestotrotz haben wir auch das ganze Spektrum. Von Leuten, die am Wochenende einfach mal ein komplettes Feature auf eigene Faust refactored haben und am Montag kommen und sagen, guck mal, ich habe mal was probiert, zu Leuten, die sagen, nee, Moment, ich habe hier absolute Bedenken, dass uns das ins Verderben bringt. Oder sowohl ethische Bedenken als auch eben Code-Qualitätsbedenken. Die klassischen Argumente, wie kann ich noch sicherstellen, dass der Code das tut, was er tut, wenn ich nicht mehr verstehe. Also wir haben fairerweise das ganze Spektrum. Ich glaube schon, dass wir in der privilegierten Situation sind, dass es eher bei uns die Affinitäten gibt. Aber auch wir haben die Herausforderungen, alle mitzunehmen, ein gemeinsames Set von Best Practices zu entwickeln und so weiter.
SPEAKER_01Wie ist denn das Thema Refactoring? Wie hat das bei euch funktioniert? Also ich höre da sehr unterschiedliches Feedback aus der Industrie. Bei den einen funktioniert super, die anderen sagen, es ist Vollkatastrophe. Wenn es um so Refactoring geht, was habt ihr für eine Erfahrung gemacht?
SPEAKER_00Ich glaube, abschließend kann man es noch nicht genau sagen. Also, wir hatten beide Fälle schon. Wir hatten eben Fälle, wo man beeindruckend schnell Technical-Debt-Sachen aufarbeiten konnte. Wir hatten aber auch Fälle, wo es einfach, wo wir dann halt die Entwickeln sagen, puh, dieser Pull-Request, der hat irgendwie, weiß ich nicht, 10.000 Zeilen auf Code. Wir haben jetzt gerade gar kein riesiges mehr Gefühl mehr, ob das jetzt verbessert wird oder verschlechtert wird. Da sind wir fairerweise auch noch in der Findungsphase, wie man es gut schneidet, wie man den Scope richtig wählt, wie man gerade beim Testen und so weiter wirklich sicherstellt, dass es am Ende das tut, was man möchte und dass es dann nicht im Long Run irgendwie eben doch langsamer ist oder eben schlechter ist als vorher.
SPEAKER_01Ja, ich frage mich auch, was ist denn eigentlich heutzutage der Maßstab, um ein Refactoring noch zu machen? Wenn natürlich, wenn man annimmt, dass auch wenn der Code aus menschlichen Clean Code und Engineering-Gründen nicht mehr ideal ist und schlecht wartbar ist. Die AI hat ja gezeigt, dass sie auch solchen Code oft sehr gut verstehen kann und auch noch weiterentwickeln kann. Was ist dann noch der Grund, das zu refactoren? Ist es Performance oder was genau ist es? Oder weil du einfach nochmal was Neues dran bauen möchtest und dann kommst du um das Refactoring nicht drum herum?
SPEAKER_00Das ist eine gute Frage. Ich glaube, jetzt hat man eben so eine Mischsituation, wo Mensch und Maschine auf der gleichen Codebasis versuchen zu arbeiten. Aber wie du richtig andeutest, wir werden, und das ist eine Aussage, die ich fest glaube, dahin kommt, dass Menschen keinen Code mehr schreiben. Dass quasi, es wird irgendwann passieren, dass nur noch Maschinencode schreiben, und dann ist genau die Situation, die du beschreibst, dann ist es nicht mehr notwendig zu refactor aus menschlicher Sicht. Sondern wenn die Tests, die Performance-Tests, die funktionalen Tests alle sagen, das tut das, was ich möchte, dann ist mir ein Stück weit die Code-Struktur and Clean-Code-Sachen und so weiter, die du erwähnt hast, ein Stück Nebenrangig. Weil vielleicht die Maschine in einer anderen Struktur. die sie besser versteht und wir Menschen eben sie vielleicht dann nicht mehr lesen können.
SPEAKER_01Ist dir bewusst, dass du mit der Aussage, dass du sagst, wenn du, dass wir irgendwann der Mensch nicht keinen Code mehr schreiben wird, dass du ja damit nicht viele Freunde, also viele Feinde machen, ich würde nicht Feinde sagen eigentlich, aber du wirst ja viele Freunde machen damit.
SPEAKER_00Alles gut, also das ist bewusst vielleicht ein bisschen provokant formuliert. Natürlich ist es ein Spektrum, natürlich kann es sein, dass man hier und da als Mensch, also wir müssen den Menschen im Prozess behalten, auf alle Fälle. Er wird seine Rolle behalten müssen, auf alle Fälle. Aber sie wird eben nicht mehr sein, Charakter in eine IDE zu tippen, ist meine These. Also es wird im Review-Prozess auf alle Fälle natürlich notwendig sein, dem Mensch drin zu haben. Aber die Rolle wird sich extrem wandeln. Und wir hatten das, glaube ich, in unserem Erstgespräch schon, als Hochsprachen entwickelt worden sind, gab es, glaube ich, auch viel Aufschrei über, ich kann nicht mehr verstehen, wie das dann auf Assembler abgebildet ist. Und heute glaube ich, dass sich niemand mehr Gedanken darüber macht, wie der Compiler am Ende etwas auf die Maschinenebene bringt. Und genauso wird das mit KI passieren.
SPEAKER_01Ja, und ja, genau, es ist immer die Frage, wie viel vom Code muss der Mensch verstehen. Ich glaube, am Ende des Tages sollte der Mensch theoretisch in der Lage sein, alles zu verstehen. Die Frage ist, muss er es verstehen? Und selbst das Verstehen muss ja nicht bedeuten, er liest jede Zeile Code. Denn in einer Welt, in der so viel Code entsteht wie noch niemals zuvor und wie noch in den letzten 30 Jahren zusammengerechnet nicht, entsteht jetzt auf einmal, da kannst du ja gar nicht mehr alle zeilen, Review. Und da kannst du immer nur die Intentionen oder das Ergebnis absichern. Die Frage ist, akzeptierst du das? Und wer ist bereit, das nicht zu akzeptieren? Ich erlebe es, ganz viele Engineers sind dazu noch nicht bereit, vielleicht weil die eigene Identität damit zusammenhängt. Ich weiß es nicht, aber ja.
SPEAKER_00Ich glaube schon, Philipp, das ist, glaube ich, ein wichtiger Punkt und der ist ganz weit weg von Technologie. Der ist halt eher im Soziobereich und zu sagen, wie schaffen wir es den Leuten, das Vertrauen zu geben, dass diese Technologie ihnen nicht den Job nimmt, sondern ihn irgendwie anreichert oder positiv verändert zumindest. Aber auch ein wichtiges Statement und vielleicht auch zum Thema Kontroverse, KI wird nicht mehr weggehen. Wir werden nicht, es ist nicht die Frage als softwareentwickelnde Person, ob ich das nutze, sondern die Frage ist nur, wie nutzt du es, wie gut bist du in der Lage, das zu nutzen. Also sich dem Thema zu verwehren, kann man machen, aber ich glaube nicht, dass es eine Option ist. Also es wird bleiben.
SPEAKER_01Das ist ein sehr wichtiger Satz und ich würde ihn auch nochmal unterschreiben. KI wird nicht mehr weggehen. Selbst wenn jetzt irgendjemand auf die Idee käme zu sagen, wir stellen jetzt die AI-Entwicklung komplett ein, das wird nicht passieren. Das kann sich keiner leisten, jetzt nicht weiterzuentwickeln. Weder Unternehmen, die diese Modelle einsetzen, als auch diejenigen, die an neuen Frontier-Modellen arbeiten. Du kannst es dir einfach nicht leisten, auf die Stopp-Taste zu drücken. Und das ist natürlich eine Entwicklung, wo du sagst, naja, was muss denn, also wo wird uns das denn noch hinführen? I don't know. Wir wissen es wahrscheinlich alle nicht. Aber ja, du kannst das nicht mehr zurückdrehen. Das Ding ist da und es wird nie wieder weggehen.
SPEAKER_00Und es wird, und um es noch drastisch zu formieren, wir sind am Anfang. Also man trotz der beeindruckenden Ergebnisse, die wir heute sehen, ich glaube, es gibt viele Anzeichen dafür, dass noch viel, viel kommen wird und dass es gar nicht mehr so weit weg ist, dass noch mehr Dinge sich revolutionieren und die Qualität, die Ausgaben dieser Modelle noch besser wird.
SPEAKER_01Hast du eine Prognose oder eine Vision, was wir sehen werden im Jahr von jetzt an, in zwei Jahren, in fünf Jahren?
SPEAKER_00Das ist, glaube ich, sehr schwer. Also wenn man auch den großen CEOs folgt von Entropic und so weiter, die tun jetzt auch schwer. Es gibt da ein Korridor, glaube ich, von wir gehen ganz stark in AGI hinzu, es wird stagnieren. Also ich glaube, da gibt es fairerweise keine vertrauensvolle Vorhersage. Was man aber sagen kann, wir hatten jetzt, die ein bisschen tiefer drinstecken, es gab es die Mythos-Modellklasse von Anthropic, Fable 5 und das hat es zumindest geschafft, so gut zu sein, dass es der US-Regierung so viel Angst gemacht hat, dass es verboten worden ist. Und das zeigt ja schon mal, dass wir da, dass es noch viele Dinge gibt, die gerade, glaube ich, schon in den Laboren und so weiter gären. Und ich glaube schon, dass wir, wenn wir sagen, am Ende des Jahres, in einem Jahr, wird es Agenten geben, die wirklich das Thema autonome Softwareentwicklung so gut beherrschen, dass wir keine Bauchschmerzen mehr haben, sie auch wirklich einzusetzen. In typischen Umfeldern wie Webentwicklung, Java und so weiter, also jetzt nicht vielleicht sehr spezialisierten Feldern, aber in diesem ganz allgemeinen Projektgeschäft, wo viele unterwegs sind, wird es, glaube ich, in einem Jahr schon sehr, sehr, sehr gute Modelle geben.
SPEAKER_01Ende des Jahres, sagst du? Okay, ja, das ist ein guter, das ist eine nicht sonderlich steile These. Ich würde dir sogar mitgehen zum Thema Fable. Wir haben jetzt, wir nehmen ja heute am 3. Juli nehmen wir auf. Vor zwei Tagen ist Fable 5 ja wieder released, also neu released worden, aber ich habe jetzt mehrere schnelle, also innerhalb von zwei Tagen hat keiner eine vollständige Studie gemacht, aber die ersten Tests, die da wohl gefahren wurden, man hat dieses Modell doch arg beschränkt in dem, was es an Möglichkeiten hat. Also es heißt immer noch Fable 5, aber es ist wohl gerade beim Thema Refactoring und beim Thema Debugging, ist es wohl wesentlich schlechter als vorher. Hast du das auch schon mitbekommen?
SPEAKER_00Ich habe nur die Mail bekommen von es wurden ja Mails verschickt an Leute, die einen Account haben, dass es jetzt wieder verfügbar ist. Ich musste ein bisschen schmunzeln. Und ich habe es nicht getestet, aber es war schon meine Vermutung, es muss irgendein Abkommen geben, warum es jetzt wieder verfügbar ist. Ich glaube, und das ist natürlich ein Aspekt, da kann man auch, glaube ich, einen ganzen Podcast füllen. Das ist eine Gefahr, die auch bei uns intern sehr diskutiert wird. Wie abhängig macht man sich am Ende des Tages von bestimmten Modellen oder bestimmten Anbietern und wie sehr wird dann auch die Politik irgendwann ein Thema. Also wir sind eben in Deutschland nicht die, die die Modelle selber bauen oder die irgendwie die Firmen beherbergen, die diese Modelle gebaut haben. Und dann ist es halt in der Hand derer, der Staaten, wo die herkommen, ob auch andere Länder davon profitieren oder nicht oder ob sie eben von heute auf morgen sagen, leider keinen Zugang mehr. Also das ist ein valides Argument, wie wir als Europa, als Deutschland darauf in Zukunft eigentlich reagieren wollen.
SPEAKER_01Also machst du dir Gedanken auch darum, ab wann es denn Sinn macht, auch für euch als Unternehmen, eigene Modelle zu trainieren? Ich meine, aktuell, du kannst ja gesagt, ja, ich habe halt hier meine Vektordatenbank, wir haben hier unser Rack und das nutzen wir, das heißt, wir reichern unsere Prompts, bevor wir sie zum LLN schicken, reichern wir mit dem jeweiligen Kontext an und das reicht völlig aus. Aber du könntest ja genauso hingehen und könntest sagen, ich trainiere ein eigenes Modell, ich trainiere nach, ich verfeinere das und dann lasse ich das auf meinem eigenen Modell laufen. Macht dir sowas, machst du dir über sowas Gedanken?
SPEAKER_00Also tatsächlich ist es lustigerweise das, wo ihr beiherkommt. Also vor fünf Jahren, wo dieses Sprachmodellthema jetzt noch nicht so präsent waren, auch die Verfügbarkeiten, gab es ja eher kleinere Open Source Sprachmodelle wie BEART oder sowas, die im Per Hacking-Phase zur Verfügung standen. Und dann haben wir genau das getan, haben dann quasi kleine, vortrainierte Modelle genommen und sie so gesehen overfittet auf Business Cases, die wir hatten. Und das machen wir tatsächlich vor, wenn es zum Beispiel eben compliance-mäßig notwendig ist, dass Dinge sehr isoliert laufen oder nicht rausdürfen. Aber ich glaube, man darf sich nicht der Illusion hingeben, dass man in der Lage ist, ich weiß nicht, wie viele, eine Million Grafikkarten, die Tesla oder eben XAI quasi im Bestand hat, da irgendwie realistischerweise eine Antwort drauf zu haben. Also man kann für einen Spezialfall mit sehr abgeschlossenen Use Case, glaube ich, gute Modelle irgendwann auch selber trainieren. Aber ich glaube, in der Generizität und der Mächtigkeit, jetzt eben solche Mythos-Modelle oder die letzten Modelle, die es gerade im Markt gibt, sind schon echt hart nachzubauen, sage ich mal.
SPEAKER_01Ich glaube, nachbauen ist nicht die Antwort, sondern es ist dann immer nur auf speziellere, sehr persönlichere Use Cases dann hin nachzutrainieren, um sie dahingehend besser nutzbar zu machen. Und vielleicht kannst du dann auch ein europäisches Modell wie Mistral oder irgendwas nehmen und kannst dann damit auch was machen. Ich habe keine Ahnung, ich habe mit Mistral selber noch nicht gearbeitet. Was nutzt ihr für Modelle intern? Also sowohl zum Beispiel für die Entwicklung als auch für euer Produkt, kannst du das sagen?
SPEAKER_00Also für das Produkt ist es ein bisschen, sag ich mal, vielleicht nicht so öffentlich, aber wir haben in der Entwicklung, versuchen wir möglichst breit gerade aufgestellt zu sein, indem wir quasi die Modelle von Cloud, also auch von OpenAI, zugänglich machen. Wir haben auch ein Open Lama immer noch für kleine Sachen und versuchen da möglichst breit erstmal zu sein, dass in der Entwicklung oder in der Organisation viel erstmal experimentiert werden kann. Dass wir erstmal verstehen, welche Modelle haben jetzt welchen Unterschied. Gerade in der Cloud-Familie hat man ja auch eine große Abstufung von Preis und Qualität. Und das ist vielleicht auch, glaube ich, viele Leute stehen gerade an dem Punkt, die Entwickelnden und die Menschen in der Organisation ermächtigt zu haben, die Tools zu nutzen. Das aus meiner Sicht so die erste Welle. Man hat es überhaupt erstmal geschafft, dass Leute es nutzen. Und die zweite Welle ist jetzt zu wissen, okay, wie kriegen sie das eingefangen? Wie kriegen wir das irgendwie lizenztechnisch das so hin, dass wir nicht jede Woche merken, okay, die Tokens steigen, steigen, steigen. Wir zahlen 3000, 4000, 5000, 10.000 Dollar im Monat. Wie kann man das gut handeln? Na, hat jeder ein gewisses Budget? Hat man irgendwie einen Threshold, wo es hart abschneidet, kann man dann dynamisch noch was zubuchen? Das sind so Themen, die dann ja da auch die Frage bedingen, wie viele Modelle lässt du im Unternehmen zu, von welchen Anbietern und so weiter.
SPEAKER_01Wie viel Geld gibst du aus im Monat für Modelle? Also nicht du persönlich, sondern euer Unternehmen? Also jetzt für die für interne Entwicklung, jetzt nicht fürs Produkt, sondern nur für interne Prozesse.
SPEAKER_00Noch vierstellig, aber ja. Also schon ein bisschen, sage ich mal. Also es sind schon Personentage oder Personenmonate fast.
SPEAKER_01Ja, also ich zucke da jetzt gerade nicht, weil ich kenne andere CXOs, die sind schon bei knapp sechsstellig. Das sind auch große Unternehmen, aber die sind, ja, die haben die haben halt natürlich auch eine gewisse Anzahl von Leute, die da drauf gehen, aber da geht nicht alles auf Subscriptions drauf, sondern da wird auch fleißig Tokens investiert, die halt über die API direkt verbraten werden. Und ja, irgendwann ist der Geldbetrag für jedes Unternehmen so groß, dass ein CFO mal drauf schaut und dann die Frage stellt, naja, was ist denn eigentlich der Return on Invest von dem, was wir hier tun?
SPEAKER_00Und das ist, wenn ich da fil, glaube ich, einer der Punkte, auch wenn wir sagen, wo stehen wir gerade und worauf sollten Leute auch achten, ist genau der Punkt. Ich glaube, der erste Schritt ist immer erstmal Enablement, die Leute ins Doing bekommen, die Leute sich damit vertraut machen zu lassen, indem sie es selber ausprobieren, sie motivieren, mal etwas auszuprobieren. Es kostet ein bisschen Geld, das kostet eben das Vertrauen, dass Leute das nicht ausnutzen in Form von Token-Konsumption, wie du es gesagt hast. Aber der nächste Schritt muss eben sein, das Ganze in klare Strukturen zu packen und eben zu sagen, wie sind die finanziellen Rahmenbedingungen oder eben, was kannst du wie tun und die Leute dann ein bisschen quasi in die Struktur geben und da gehört Messbarkeit dazu. Eben sich klar zu werden, was sind meine Ziele mit dem Einsatz von AI. Ich mache das jetzt nicht nur, weil es cool ist, sondern irgendwie will ich ja organisatorisch ein Ziel erreichen, beschleunigende Entwicklung, mehr Features, bessere Qualität und die dann wirklich messbar machen. Also wirklich zu sagen, wenn wir keine AI hätten, ist unsere Recycle-Time für Features XY und dann haben wir mal zwei, drei Testgruppen mit Agents ausgestattet und die zwei Leute beobachtet und die Cycletime ist um 20 Prozent gesunken. Und das muss man dann im zweiten oder dritten Schritt dann wirklich aktiv machen, dass man dann sich wirklich damit auseinandersetzt, was sind denn die Mehrwerte, die den Kosten gegenüberstehen.
SPEAKER_01Wie müsst du das noch außer Cycletime oder ist Cycletime für dich so die Hauptmetrik gerade?
SPEAKER_00Also das ist ja eine Frage der Zielstellung. Du kannst ja auch, also ich bin jetzt mal das ganze Spektrum auf, du kannst sagen, du wirst einfach ein innovatives Unternehmen sein, du wirst einfach deinen Mitarbeiter zufrieden machen, neue Technologien zu nutzen, du willst bessere Qualität in deinem Produkt haben, du willst schneller öfters Features releasen. Das hängt ja davon ab, was dein Ziel ist mit diesem Einsatz von KI. Wenn man jetzt sagt, ich will gerne schneller und besser neue Features releasen, dann sind es genau diese Themen, Cycle-Time von Features, von quasi Ticket geht ein zu Deployment hat stattgefunden. Dann hast du natürlich die Gegenbewegung, wie oft wurde was als Fehler markiert oder gab es irgendwie ein Ticket vom Kunden, dass etwas nicht funktioniert hat. Geht diese Zahl hoch, geht sie runter. Mitarbeiterzufriedenheit, also einfach zu gucken über Mitarbeiterbefragungen in regelmäßigen Abständen, wie zufrieden sind die Leute mit ihrer Arbeit, wie wirksam fühlen sie sich, wie gestresst sind sie. Man hat ja nach wie vor noch dieses große Thema, was heißt das eigentlich, dass du eben nicht mehr zwei Stunden Codest, zwei Stunden Reviews, eine Stunde Abstimmung hast, sondern eigentlich de facto den ganzen Tag nur noch Reviews und krass permanent Kontext-Switch machst, krass permanent dich immer wieder sehr hart konzentrieren musst, auf etwas zu kontrollieren, hat man auch noch keine Langzeiterfahrung, was das eigentlich bedeutet in der Produktivität oder der Effizienz von Mitarbeitenden. Das heißt, da gibt es verschiedene Metriken, die ein bisschen danach ausgerichtet werden müssen, was eigentlich dein Ziel mit dem Einsatz ist.
SPEAKER_01Ja, ich muss ehrlich sagen, ich bin mehr gestresst dadurch. Also ich, also ganz ehrlich, ich liebe es, ich liebe es damit, nicht zu spielen, wird es zu vereinfachen. Ich liebe es, damit zu arbeiten, ich liebe es damit, Prozesse zu automatisieren, ich liebe es, um meine Produktivität hochzumachen, aber ich merke, das ist, du bist in einem konstanten, in einer konstanten Anspannung, weil ständig irgendwas auf deinen nächsten Input wartet, wenn du dann mehrere Agents hast und die Tatsache, dass sie da stehen und warten auf deinen Input, bringt dich ja nochmal Entzugzwang. Und das ist auf Dauer, baut das so eine Art Druck auf. Natürlich kann ich jederzeit sagen, jetzt mache ich halt mal irgendwie weniger, aber man tritt ja an, um effizienter zu sein, um produktiver zu sein und dann begibt man sich in so eine Spirale und dann stellt man fest, die können immer schneller als du selbst. Und da kommst du halt nicht mehr raus, so einfach. Du hast eben noch was gesagt zum Thema Cycletime und das finde ich interessant. Ich bin mir nämlich ehrlich gesagt gar nicht so arg sicher, ob Cycletime so die richtig gute Kenngröße dafür ist. Jetzt ist es natürlich schön, wenn du sagst, die ist bei euch 20% runtergegangen, aber es gibt ja auch den Fall, dass du durch die Tatsache, dass du, dass Teams in der Lage sind, innerhalb eines Sprints auf einmal viel komplexere Storys zu machen, ist vielleicht die Anzahl an Storys und die Länge, die eine Story dann braucht, um von Beginn bis zum Ende bis zur Lieferung durchgeht, ist vielleicht gleich. Es sind halt nur größere Storys. So, die Cycletime misst ja weder Größe noch Komplexität noch sonst was, sondern einfach nur, wie lange dauert es vom Beginn bis zum Ende. Und ich glaube, in vielen Fällen wird das dem Impact von AI nicht gerecht, wenn man sich nur auf die Cycletime verlässt.
SPEAKER_00Absolut. Aber zur Wahrheit gehört, glaube ich, auch, dass es eben super schwer messbar ist. Das ist generell auch ein sehr großes Thema. Wie misst man die Effizienz von Personen, die Software entwickeln und irgendwie bewertet die, wenn man das wollte. Und ich glaube, da hat man das gleiche Problem. Wenn man jetzt, wie kann man Messbarkeit herstellen, indem man es vereinheitlicht und wenn man irgendwie einen Maßstab dran hält. Aber wir auch diskutieren das sehr intensiv intern, wie man denn so eine Messbarkeit wirklich objektiv hinbekommt. Weil es ist super leicht, glaube ich, etwas zu messen, was einem vermeintlich etwas zeigt, aber eben die Datengrundlage eigentlich falsch ist oder irgendwie falsche Indikatoren liefert. Also absolut bin ich bei dir. Nur noch ein Gedanke, aber ich glaube eben auch, dieser Schritt in Level 4, 5, was du beschrieben hast, geht eben über dieses kleine Pakete. Also dieses definitiv muss der Anspruch sein, in Zukunft sehr komplexe Systeme am Ende zu Ende generieren zu lassen. Aber gerade bei dem Thema Vertrauen und Qualität der Modeller geht es, glaube ich, nur über lass es klein, mach es kontrollierbar und kontrolliere, ob es das ist, was du möchtest.
SPEAKER_01Ich glaube tatsächlich, also und habe es selber auch schon damit ausprobiert, das funktioniert tatsächlich gut. Es ist natürlich nicht wissenschaftlich genau, aber ich bin, ich lasse mittlerweile Agents Komplexität von Storys messen. Und ich lasse es also an Wirklichen, wie du Storypoints in Scrum misst, nach Fibonacci und so weiter, ich lasse das überhaupt nicht mehr Menschen machen oder die Engineers, die sich ja sowieso nur streiten, dass Komplexität ein bisschen Quatsch ist und die sich nicht darauf einigen können, was bedeutet jetzt Komplexität, sondern du definierst am Anfang in deinem Projekt oder in deinem Backlog definierst du halt auch deine Baseline-Story, die in Relation zu dir das alles gemessen wird. Und das Ergebnis davon ist erstmal good enough und genau genug, dass du halt eine Tendenz siehst. Und dann wirst du merken, dass du natürlich im Laufe der Zeit in der Lage bist, immer eine immer bessere Velocity an den Tag zu legen und das zu tun. Da kannst du tatsächlich den Impact messen, weil du da natürlich in dem Sprint auf einmal viel mehr Komplexität liefern kannst, einfach weil deine Durchsatz halt viel schneller ist. Und dann kannst du dir sogar über Gedanken machen, jetzt hören alle Engineers mal bitte komplett weg. Du kannst dir ja sogar überlegen, dass du anfängst, noch deine Gehälter mit Storylines in Verbindung zu, mit Storypoints in Verbindung zu bringen. Dann kannst du dir ausrechnen sogar, wie viel dich ein Storypoint in der Vergangenheit vor der AI-Ära gekostet hat. Und dann kannst du noch deine AI-Kosten jetzt mit reinrechnen und deine Mitarbeitergehälter und kannst dann ausrechnen, wie viel bringt dir ein Storypoint denn, was kostet der dich denn jetzt in einer Zeit, in der du Agentic AI nutzt. Und ich finde, das ist ein sehr interessanter Weg, auch um im Bord oder gegenüber Investoren zu zeigen, was kann ich denn, also was ist der Impact von Agentic AI. Und das geht ein gutes Stück über Cycle Time hinaus. Ich finde, Cycletime ist auch wichtig, aber ich glaube, der Cycletime allein gibt dir nicht die richtige Antwort dazu.
SPEAKER_00Absolut fairer Punkt. Ich glaube, bei deinem Szenario ist natürlich, also dann hast du die Gefahr, dass du die beiden Welt ein bisschen gegeneinander ausspielst. Also der Ei wird es egal sein, was die andere Welt macht, aber wenn eben dein Maßstab ist, der Mitarbeitende muss die gleiche Leitung, oder du kämpfst gegen die Performance der KI, könnte es nicht unbedingt dazu bringen, dass die Mitarbeitenden wohlwollend gegenüber KI eingestellt sind und dem.
SPEAKER_01Nee, das meinte ich gar nicht. Ich meinte eigentlich eher, also natürlich will ich wissen, was hat mich vorher ein rein menschlicher Storypoint gekostet. Ich sage jetzt mal, der kostet dann wegen mir 10.000 Euro mich gekostet. Und jetzt muss ich ja nicht nur, jetzt bin ich in der Lage, vielleicht fünf Storypoints mehr im Sprint zu machen, habe aber durch Agent TKI auch nochmal irgendwie 50.000 Euro mehr kosten. So ist dann der Impact von Agent TKI, in welcher Relation steht er zu dem, was ich eigentlich vorher für Zeit und Kosten halt hatte. So ist das, geht diese Glücke auseinander oder ist das in einem gesunden Verhältnis zueinander? So, das ist interessant, wo sich das hin entwickeln wird. Und da geht es nicht darum, dem menschlichen Engineer was vorzuhalten, weil dass der nie in der Lage sein wird, so schnell, so viel, so komplex zu arbeiten wie der Agent. Ich glaube, das ist uns allen klar. Und dieses Rennen werden wir gar nicht erst eingehen.
SPEAKER_00Ja, ja. Nee, absolut, da hast du vollkommen recht. Und wie gesagt, ich glaube, es ist ein komplexes Thema. Wie misst man das? Dein Ansatz ganz spannend, aber auch da, was sind am Ende meine Ziele und du hast ein Thema tuschiert, was ich, glaube ich, auch ganz wichtig ist zu erwähnen, wenn es darum geht, wo kämpfen eigentlich gerade die Unternehmen oder wo ist gerade die größten Fragezeichen, das Thema Datengrundlage. Also für mich, also dieses, wir nutzen Agenten oder wir stellen den Mitarbeitenden so eine Agentenplattform hin. Das ist gut und schön. Aber ich glaube, und wir hatten es am Anfang Hype und Ernüchterung, ich glaube, die Ernüchterung jetzt ein bisschen ist, dass es eben nicht so ein Out-of-the-Box-Ding ist, sondern um richtig gute Ergebnisse zu erzielen, brauchen die Agenten halt den richtigen Kontext, den richtigen Zugriff und die Daten müssen in einer gewissen Art und Weise strukturiert und verfügbar sein. Und das ist im ersten Schritt wichtig für eine Person, aber dann noch viel wichtiger Unternehmensweit hinzubekommen. Weil hoffentlich haben irgendwann 50 Prozent deiner Mitarbeitenden ihre Agentenlandschaft aufgebaut und jeder von denen fängt an, das, keine Ahnung, das Org-Chart, die CS-Regeln, dass die SLAs des Unternehmens und so weiter einzeln in die Knowledge Base zu packen, jeder auf eine andere Art und Weise und keine ist im Sync, sobald eine Änderung kommt. Und das ist eine Herausforderung, die Unternehmen meistern müssen, wie schaffen wir es jetzt unser Unternehmenswissen, unsere Unternehmensdaten einheitlich agentengerecht so zu bereit zu bestellen, dass alle das nutzen können.
SPEAKER_01Das ist etwas, was Unternehmen gerade massiv unterschätzen, die Arbeit, die da noch reinfließen muss, oder nehmen sie das wahr und sind schon dran und es dauert nur?
SPEAKER_00Ich glaube, da würde ich jetzt nicht pauschalisieren. Es gibt bestimmt sehr technologieaffine Unternehmen, die das durch Einzelpersonen im Unternehmen schon gut verstanden haben. Und es gibt, glaube ich, viele Unternehmen, die erstmal nur das Agenten als Passwort sehen, aber nicht sehen, dass da jetzt eine Hausaufgabe bei Ihnen auf dem Tisch liegt, um das wirklich effizient nutzen zu können.
SPEAKER_01Ja. Was unterschätzen denn Unternehmen gerade noch am meisten, außer dem Thema Kontext und Wissensdokumentation und so weiter?
SPEAKER_00Ich glaube, wir haben schon ein paar Punkte tuschiert, also dieses Thema, wie arbeite ich meine Daten auf, wie stelle ich sie strukturiert bereit, wie kann ich Schnittstellen bereitstellen, damit Agenten darauf zugreifen können. Man unterschätzt, glaube ich, ein bisschen diese Trägheit, die es braucht, dass die Menschen im Unternehmen überzeugt davon sind, es zu nutzen, das Vertrauen haben. Also es ist nicht mit ab morgen nutzen wir das alle und dann nutzen das alle. Das ist, glaube ich, ein zweites großes Thema. Es wird ein bisschen Zeit brauchen in jeder Organisation, bis quasi die Rollenmodelle, die es gerne nutzen, die Skeptiker durch gute Beispiele Stück für Stück überzeugen. Und dafür braucht es ein Rahmenwerk und eine Strategie. Ich glaube, das ist schon noch ein bisschen das Problem, dass man überschätzt, was die Agenten heute können und wie sehr man ihnen quasi am Ende des Tages autonom vertrauen kann. Das Beispiel, was du genannt hast mit den Storypoints. Ich glaube, es hat sich gezeigt, dass es immer noch gut ist, Quasi den Agenten und die Ergebnisse einen Vorschlag machen zu lassen und das ein Stück weit dann erstmal nochmal zu bewerten oder zu differenzieren und das Feedback dann wieder einfließen zu lassen und das über einen gewissen Zyklus laufen zu lassen, um dann auch sicherzustellen, dass die Guardrails oder die Dinge, die ich im Kopf habe, gut verstanden worden sind. Und ich glaube, es gibt immer noch so ein bisschen manchmal den Ansatz, das wird das schon machen, das kann das Ding ja out of the box.
SPEAKER_01Ich hätte eigentlich so gedacht, dass du mir jetzt auch noch sagst, die Kosten unterschätzen sie auch noch, weil ich glaube tatsächlich, die Kosten, die Kosten sind, sind auch noch mal.
SPEAKER_00Aber genau, definitiv, Kosten. Ich glaube, das unterschätzen gerade ganz viele, was das am Ende des Tages, was die Kosten sind. Und das ist genau das Thema, was wir hatten, können nicht so richtig beweisen, quasi, dass diese Kosten so und so viel Mehrwert oder so und so viel Einsparung oder so und so viel Added Value am Ende des Tages bringen. Genau, definitiv.
SPEAKER_01Machst du dir aktiv Gedanken? Ich meine, AI-Strategie sollte auch die in der Verantwortung des CTOs liegen, weil es halt so einen Impact hat, auch auf der technischen Ebene, aber auch auf der finanziellen und auf so vielen Ebenen eigentlich. Ist das Thema Token-Ökonomie etwas, was du dir auf die Fahne schreibst, wo du aktiv drauf schaust?
SPEAKER_00Also definitiv ja. Fairerweise eben sind wir noch in einem Punkt, dass wir gerade so ein bisschen noch ein bisschen versuchen, eher zu ermächtigen und zu motivieren. Aber wir müssen uns ganz hart auch jetzt intern den Fragen stellen, was ist unser finanzielles Limit als Unternehmen mit 100 Mitarbeitenden? Und genau diese Fragen zu beantworten, was ist eine Obergrenze, wo wir nicht denken, dass wir Innovation hemmen, aber dennoch eben finanziell planbar und wirtschaftlich arbeiten, ist definitiv ein großes Thema.
SPEAKER_01Was ist denn dann die Verantwortung des Engineers am Ende des Tages? Wenn so ein Prozess ganz viele Agents beinhaltet, ist er Ende zu Ende dann für den Code zuständig noch? Oder wo endet seine Verantwortung und wo, ja, wer ownt diesen gesamten Prozess?
SPEAKER_00Ja, oder wer ist dann verantwortlich eigentlich? Also es muss dann.
SPEAKER_01Am Ende du als CTO.
SPEAKER_00Genau, das ist in Summe bin ich es dann trotzdem, aber natürlich gelten aus meiner Sicht die gleichen Prinzipien, die auch in einer komplett agentenfreien Welt gelten, nämlich Dinge wie You Builded, you run it, so Dinge, die du baust, verantwortest du, bis sie laufen und bis sie stabil einen Mehrwert beim Kunde erzeugen. Und du solltest dir Gedanken darüber machen, was brauchst du, dass der Kunde wirklich diesen Mehrwert wirklich live bei sich im System hat? Und dieser Satz oder diese Metapher, zumindest bei uns, wird bleiben. Nur, dass man eben jetzt mit seinem Kompagnon oder seinem Coworker eben die Aufgaben teilt, aber man trotzdem in der Verantwortung bleibt, sicherzustellen, dass es nach bestem Wissen und Gewissen getestet und ausgerollt ist und den Mehrwert erbringt, den es bringen soll.
SPEAKER_01Glaubst du, wir werden in naher Zukunft viele Organisationen sehen, die wirklich auf Level 5, also mit vollautonomen Softwareentwicklungsprozessen unterwegs sein? So der Mensch wirklich nur noch irgendwo eine Spezifikation eingibt oder vielleicht die Idee eines Features, eines Scopes, eines Produkts und dann am Ende absichert, dass das Ergebnis rauskommt. Wird das der Standard sein?
SPEAKER_00Ich meine, was mit naher Zukunft im Kopf hast. Ich glaube schon, dass es. Was darfst du sagen? Dass es Leute geben wird, die das versuchen und dass es Unternehmungen gibt, die sehr, sehr, sehr hart das versuchen zu leben. Und ich glaube, um jetzt darüber nachgedacht zu haben, wird das im eingeschränkten Scope und vielleicht in einer eingeschränkten Komplexität auch möglich sein. Wir haben in der Vergangenheit gibt es diese ganzen Webseiten-Baukästen. Also irgendwie man das sich mal betrachtet, wie Webseiten sich entwickelt haben, von ich musste selber HTML schreiben zu, es gab irgendwie what I see is what I get, Editoren zu jetzt diesen Online-Sachen, wo ich eher im Word-Stil was zurechtschiebe. Und ich glaube, so diesen einfachen Softwareproblem, sage ich jetzt mal, könnte ich mir schon vorstellen, dass das noch krasser Ende zu Ende wirklich Autonomie bekommt, auch bei sehr abgeschlossenen Cases wie einer scanne alle meine E-Mails und mache das und das damit. Im größeren B2B-Kontext, glaube ich, dauert es noch ein bisschen, weil, und da sind wir wieder bei Punkten der, was sind die größten Herausforderungen, dort gibt es extrem viele Datensilos, da gibt es sehr viele Schnittstellenprobleme, da gibt es sehr viele Unklarheiten über Regeln, da gibt es verschiedene, wenn vielleicht sind manche Sachen gar nicht dokumentiert, dann sind sie unterschiedlich dokumentiert. Ich glaube, da wird es eine Zeit brauchen, bis die Agenten den Kontext bekommen, den sie bräuchten, um das hinzubekommen.
SPEAKER_01Es ist mir gerade wieder lovable eingefallen, als du diesen Baukasten da verwendet hast genannt hast, weil das ist ja im Endeffekt schon eine Art autonome Softwarefabrik. Die Riesenprompt rein und da schmeißt dir eine komplette Applikation mit Front-end, Backend und so weiter raus. Auch noch einigermaßen guter Code und eine gute Struktur. Genau.
SPEAKER_00Also deswegen glaube ich, einen gewissen Scope und auch eine gewisse nicht despektierlich, weil Einfachheit ist durchaus machbar. Du willst irgendwie für deine Essensauslieferungsfirma irgendwie einen Speiseplan-App bauen oder so, glaube ich, funktioniert.
SPEAKER_01Was bleibt denn dann am Ende des Tages die menschliche Kernkompetenz, wenn wir uns dahin entwickeln? Auch jetzt gerade vor dem Hintergrund, was macht denn dann der Entwickler? Was ist denn sein Tätigkeitsfeld? Wie verändert sich denn das?
SPEAKER_00Wir hatten das das letzte Mal schon angesprochen, ich glaube nach wie vor in diese These, dass wir alle ein bisschen mehr Produktmanager werden müssen. Also wir müssen alle ein bisschen mehr fragen, was ist jetzt hier quasi das Problem und was wäre eine gute Lösung, wie fittet quasi, also wie ist der Return on Invest, wie ist der Business Case, sage ich mal, dahinter jetzt nicht nur humanitär gedacht, sondern wirklich, was ist der Aufwand, den ich hier reinstecke, für die Lösung, die da am Ende rauskommt. Ich glaube, das mehr und mehr zu denken, ist Aufgabe in allen von uns in Zukunft, die irgendwie im Softwareumfeld arbeiten. Eben wirklich zu überlegen, was ist wirklich das Problem, was könnte hier eine Lösung sein. Aber die Umsetzung, also wie du es gesagt hast, das Schreiben von Code wird kein Problem mehr sein. Wir werden Inflation sehen von Code-Repositories, von Repos aller Art, sondern aber die Qualität, das, was rauskommt, das wird das Entscheidende.
SPEAKER_01Ja genau, und was ist denn dann die menschliche Kernkompetenz? Ist es dann das ganzheitliche Denken? Ist das das, worauf es ankommt? Also auch eine Frage, die ich mir natürlich auch selber stelle.
SPEAKER_00Ich glaube schon, auch die Übersetzung von Problemen oder zumindest das Aufnehmen des Kontextes, das ist ja auch ein Thema. Also was ist jetzt hier der Kontext, was ist das Problem und das geschickt so zu formulieren und zu verpacken, dass es klar und abgeschlossen ist. Weil ich glaube, heute scheitern schon Softwareprojekte an guten Requirement-Spezifikationen oder an klaren Absprachen. Und das wird nicht besser durch KI. Also wenn man die sehr unklaren Absprachen oder sehr unklaren Requirements in einem Prompt gibt oder in Agenten gibt, wird es genauso Fehlinterpretationen geben. Und ich glaube, das wird doch wichtiger, sich gut präzise das Problem beschreiben zu können und eben zu sagen können, was sind die Randbedingungen für eine Lösung? Also was sind meine nicht funktionalen Eigenschaften, die es haben soll, was sind meine Abnahmekriterien, damit ich sage, das tut das, was es soll.
SPEAKER_01Was siehst du denn aktuell so als das größte Risiko an, gerade wenn es um das Thema Agentec AI geht?
SPEAKER_00Gesellschaftlich oder im Kontext der Internet?
SPEAKER_01Ja, vielleicht jetzt mehr im Unternehmenskontext. Also du willst jetzt ja anfangen, Software Engineering ist jetzt das Paradebeispiel dafür. Wir wollen überall Agents einsetzen, um unsere Arbeit zu verbessern und zu verschnellern und billiger zu machen am Ende des Tages. Was ist das größte Risiko dabei? Dass wir den Engineer auf dem Weg dahin verlieren komplett? Oder worüber machst du dir da Gedanken?
SPEAKER_00Also, ein Gedanke, der mit da kommt, ist dieses Thema Ausbildung und Erfahrungsschatz. Ich glaube schon, dass wir heute sehen, dass Leute sehr erfolgreich sind in diesem agentischen Umfeld, die einen gewissen Erfahrungsschatz mitbringen in ihrer Rolle. Also sei es jetzt eben der Sales-Mensch, der entwickelnde Mensch, die HR-Person, die können, die kennen ihre Prozesse, die kennen die Herausforderungen, die kennen die Stolperfallen und können dann, glaube ich, wenn sie eine Affinität zu KI haben und Agenten relativ schnell sich Tools bauen, die ihnen dann helfen. Aber die sehr juniorischen Leute hatten diesen Erfahrungsschatz noch nicht. Und die sind jetzt ein bisschen von der Herausforderung, dass quasi Agenten ihnen viele Arbeiten abnehmen oder dass viele juniorische Tätigkeiten in ihrem Arbeitsumfeld durch Agenten betrieben werden. Das heißt, sie werden nie so richtig Chance bekommen, die Erfahrung in bestimmten Prozessen oder Aktivitäten zu sammeln, die sie eigentlich bräuchten, um später dann mal zu überlegen, wie könnte ein Agent hier einen Mehrwert liefern. Also diesen Gap zu füllen zwischen, ich bin sehr juniorisch und ich habe sehr viel Erfahrung, das wird in Zukunft, glaube ich, ein bisschen herausfordernd. Nicht nur für Software-Ingenieurs. Das ist super sehr präsent, aber ich glaube auch in anderen Rollen.
SPEAKER_01Wenn ihr jetzt nach neuen Entwicklern sucht, also Frage, sucht ihr welche und sind das dann, wie haben sich die Profile jetzt verändert?
SPEAKER_00Im Moment, ehrlich gesagt, nicht. Also wir kontrollieren auch jetzt erstmal, was bedeutet Agenten für uns, was heißt es für unsere Kapazitäten? Aber das ist auch eine Frage, die wir uns intern gestellt haben. Was wäre quasi das Profil, was jemand haben müsste, wenn er quasi neu zur Firma kommt? Und ich glaube schon, dass da, und das ist, da sind wir wieder bei diesem Slogan, KI ist da, um zu bleiben. Selbst wenn du in einer nicht-technischen Rolle heirst, musst du, glaube ich, sehr stark darauf achten, wie affin ist diese Person für dieses Thema. Er hat sie vielleicht im privaten Umfeld schon mal irgendwie Dinge probiert und so weiter, weil ich glaube, das ist ein Asset, was du in jeder Rolle leider in Zukunft irgendwie mitbringen müsstest. Selbst als Bauingenieur, als Maschinenbauer, solltest du dich, glaube ich, mit dem Thema auseinandersetzen und wirst in Zukunft Wettkampf haben mit anderen Bewerbenden, die eben gut darin sind, Agenten zu bekommen.
SPEAKER_01Ja, weißt du, was ich feststelle, ich lerne immer mehr Menschen kennen in den letzten, ja, schon in den letzten sechs Monaten da ganz extrem, die wenig bis gar kein Engineering-Background haben, aber gerade richtig steil gehen, was das Thema angeht. Weil sie ein Mindset haben und eine Art zu denken haben, die sie gerade ganz besonders prädestiniert, um ganz viel Wirkung zu erzeugen damit. Und ich frage mich gerade, müssen wir, also wahrscheinlich ist die Antwort ja, aber wie müssen wir das Thema Bildung, Ausbildung komplett anders denken? Überschätzen wir gerade komplett das Thema irgendwelcher Fähigkeiten im techlichen oder fachlichen Bereich? Und geht es nicht darum, dann eher Mindset und Denkweise neu zu schulen darauf? Das ist eine Frage, die ich mir den letzten Tag immer wieder gestellt habe, weil ich Leute jetzt kennengelernt habe, die haben vor zwei Jahren, die haben noch nie selber Software entwickelt, aber die können so krasse Sachen mittlerweile machen. Das glaubt dir kein Engineer, wenn du es ihm erzählst. Er guckt dann vielleicht auf den Kurs und sagt, er ist doch alles scheiße, aber am Ende des Tages geht es ja darum, was hast du für eine Wirkung erzeugt, was hast du für einen Output geschaffen, was hast du denn so, und ja, diese Sachen sind vielleicht noch nicht alle dann in Produktion und werden nicht von einer Million Menschen genutzt, okay. Und vielleicht ist das der Knackpunkt, aber ja, das ist so, ich komme dann noch zu keinem Ergebnis, aber ich finde das eine super interessante Frage.
SPEAKER_00Ich stehe dabei, weil diese Frage, es läuft nicht für eine Million Menschen. Wie viele Anwendungen müssen denn für eine Million Menschen funktionieren? Dann ist es nicht okay, eine Anwendung zu haben, die mein Problem für mich jeden Tag löst. Und wie du sagst, ich bin da bei dir, die ist nicht die sauberste Anwendung, die ist nicht Clean Code, aber am Ende tut sie, was sie soll. Und ich werde sie nur ein bisschen patchen oder ein bisschen anpassen, aber niemand muss die dann irgendwann mal krass erweitern und refactern. Also das ist ja, glaube ich, auch ein bisschen ein Schutzargument, zu sagen, aber es ist nicht skalierbar, wie viele Anwendungen müssen das wirklich sein? Und ich bin bei dir, viele Agenten bringen den Vorteil, dass viele nicht-technische Rollen nicht mehr auf Softwareentwickler zugehen müssen, um ihr Problem zu lösen. Und das ist doch schon mal an sich für die Gesellschaft gut. Und dafür, um das aber gut einsetzen zu können, brauchen wir definitiv Bildung und irgendwie Ausbildung dafür. Und das deutsche Bildungssystem ist nicht unbedingt dafür bekannt, sehr dynamisch auf Veränderungen reagieren zu können. Deswegen sehe ich da auch schon noch eine Herausforderung, wie wir das gut meistern können.
SPEAKER_01Ja, ich kann für das deutsche Bildungssystem stimme ich dir bei. Ich kenne leider nicht so viele andere, um zu sagen, ob die das jetzt besser machen oder schlechter machen. Aber ja, deutsches Bildungssystem ist etwas star, aber mal gucken, wo wir da rauskommen. Gregor, wir sind leider wieder am Ende der heutigen Ausgabe. Aber du kennst das mittlerweile. Wir haben eine Runde Rapid-Fire-Fragen mit dabei. Wenn du noch ein paar Minuten Zeit hast, nehmen wir uns, Digi, sehr gerne. Nehmen wir uns gerne. Sehr schön. Dann der große Frage wie immer, AI Agents, und diesmal wirklich auf die Agents bezogen. Ist das mehr Hype oder ist das schon Brutalrealität?
SPEAKER_00Ist schon Brutalrealität.
SPEAKER_01Und der größte Fehler, den die Entscheider gerade beim Thema AI machen aus deiner Sicht?
SPEAKER_00Du lange abwarten.
SPEAKER_01Guter Punkt. Welche Rolle wird durch Agenc AI am stärksten verändert?
SPEAKER_00Diese Software entwickeln, also muss man sagen. Es wird viele Rollen beeinflussen, aber der Softwareentwickeln, der wird schon massiv sich verändern.
SPEAKER_01Hättest du das vor einem Dreivierteljahr gedacht? Nein.
SPEAKER_00Also so ein Ausmaße nimmt, hätte man, glaube ich, nicht erwartet. Und es ist ja ein bisschen Ironie des Schicksals, dass man sagt, dass die Modelle gerade das ersetzen, was quasi, was sie erschaffen hat. Aber es ist natürlich, wenn man den Hintergrund kennt, total verständlich. Es gibt unheimlich viel Source-Code im Internet. Es gibt unheimlich viele Foren-Stack-Overflow-Dinge, die erklären, was Bad Pattern sind, was Good-Pattern sind. Und natürlich können die Modelle das jetzt.
SPEAKER_01Ja, interessant davon vor irgendwie zwei Jahren habe ich mit einem anderen CTO gesprochen und habe gesagt, ja, das ist natürlich der Outcome von AI, was Coding angeht, ist natürlich unterer Durchschnitt, weil das ist auch die Qualität, die mittlere Qualität, die du halt online findest, wenn du, wenn du nach Code suchst. Aber das hat sich ja mittlerweile, und das hat vor zwei Jahren auch noch gestimmt. Und das stimmt halt mittlerweile nicht mehr. Also die Baseline hat sich natürlich schon sehr arg nach oben verschoben und ist mittlerweile auf einem sehr guten Senior-Level unterwegs. Natürlich wirst du immer noch einzelne Engineers finden, die besser sind als das, was die AI kann, aber es werden immer weniger. Und wir haben vorher mal vom Thema Stagnation gesprochen. Ich weiß nicht, ich sehe sie aktuell, ehrlich gesagt, noch nicht. Vielleicht kommt sie irgendwann, aber aktuell sehe ich eigentlich eher, selbst wenn die Modelle sich nicht in der gleichen Geschwindigkeit evolutionär weiterentwickeln, ist aber das, was du drumherum machen kannst, das Tooling und das Arbeiten damit, allein dadurch, dass sich das nochmal so sehr weiterentwickelt, befeuert das den gesamten Bereich auch noch. Deswegen, also für mich ist das Thema Stagnation, ich sehe es nicht. Vielleicht ist das ein großer Fehler von mir, aber ich sehe es einfach nicht.
SPEAKER_00Nee, bin ich absolut d'accord, weil man eben diesen Punkt sehen muss, wie es ja ist in der Fläche schon. Und da gibt es, glaube ich, schon noch viele Potenziale in der Fläche, wo die Modelle in der Qualität, wie sie heute sind, schon einen Mehrwert liefern können. Und jetzt noch mehr Leute, wie du es gesagt hast, Leute, die vor zwei Jahren noch nicht annähernd an Softwareentwicklung gedacht haben, jetzt auf einmal merken, hey, kann ich mein Problem selber lösen. Ich dachte, da sind wir auch noch ganz früh unterwegs und da wird es noch ganz viele Themen geben.
SPEAKER_01Braucht jedes Unternehmen eine AI-Strategie oder eher eine Prozessstrategie mit AI?
SPEAKER_00Der Prozessexperte Gregor darf dann antworten. Ich glaube, es ist keine Option, gerade zu sagen, wir warten erstmal ab, wir gucken mal, wie sie sich entwickelt. Weil das Momentum ist da, es bewegt sich unheimlich schnell. Und wie du hast gesagt, das würde es Firmen geben, die komplett agentisch denken, ja. Das heißt, du musst auf alle Fälle dich hinterfragen, was ist mein Geschäftsmodell, was ist mein Burggraben gegenüber anderen Firmen, die am Wochenende zutritt, mit einem Agenten das Ding nachbauen. Und das heißt, ich würde schon sagen, jedes Unternehmen braucht eine KI-Strategie. Und wenn die sagt, wir müssen unsere Prozesse klarziehen oder wir müssen als ersten Schritt unseren Knowledge Base klarziehen, okay, aber man muss sich aktiv damit auseinandersetzen, was bedeutet KI für uns und die positionieren wir uns. Und ich glaube, es ist ein aktiver Fehler zu sagen, wir warten erstmal ab im U.
SPEAKER_01Was ist euer Mode, was ist euer Burggraben?
SPEAKER_00Prozesswissen, Domänenwissen und Determinismus ist ein wichtiger Punkt.
SPEAKER_01Sehr gut. Ein Skill, den jeder CTO lernen sollte.
SPEAKER_00Den er heute nicht hat, meinst du, oder generell? Ich glaube, jetzt tatsächlich, wir hatten das letzte Mal schon, musst du als Führungskraft wieder viel präsenter sein. Also wir haben zum einen das Thema, dass man natürlich die anderen ermächtigen muss und sie in die Lage versetzen muss, zum Beispiel mit Agenten Dinge zu tun, aber jetzt gerade in der Dynamik der Zeit und dem musst du sehr präsent sein und mit klaren Visionen, sag ich mal, vorangehen und sagen, hey Leute, wir wollen das, wir wollen Agenten, wir machen das und wir gehen jetzt vorwärts. Also ich glaube, dieses Leadership-Thema und da visionär strategisch denken, das ist super wichtig gerade für CTOs.
SPEAKER_01Ich glaube tatsächlich, CTOs müssen wieder sehr viel mehr Hands-on sein, als sie das noch vor fünf Jahren-Seiten sein müssen. In der Phase, wo die Hauptaufgabe eines CTOs war, Hauptsache Wachstum und ganz viele Entwickler einstellen und neue Standorte aufmachen und Plattformen bauen und sowas. Da wurden die Organisationen immer größer und da ging es halt um andere Themen und mittlerweile, also ich würde meine AI-Strategie nicht bei einem Seniorentwickler überlassen, egal wie gut der ist, weil der guckt in der Regel nicht auf das gesamte Unternehmen oder auf den gesamten Prozess, der guckt auf einen kleinen Ausschnitt da draußen und da wird er halt gut sein. Aber also ich glaube, Organisationen, Engineers, der gesamte Software Development Lifecycle, der sucht und lächt nach Direction, also nach Richtung. Und ich glaube, wir sind alle in einer Phase, wo wir einfach ausprobieren und ausprobieren müssen, um da hinzukommen. Und das ist CTO-Aufgabe.
SPEAKER_00Und den Mut zu haben, Entscheidungen zu treffen mit Unsicherheit. Das ist eine Wette. Und die muss jemand treffen.
SPEAKER_01Dann letzte Frage für heute. Ein Satz, den du jedem Entwickler heute mitgeben würdest.
SPEAKER_00Hast du schon Agents ausprobiert?
SPEAKER_01Wenn die Antwort nein, ist, ist das Interview schnell vorbei.
SPEAKER_00Nein, einfach im Sinne, wie du es gerade sagst, wir müssen es ausprobieren. Wir dürfen nicht theoretisch drüber reden. Wir alle müssen ein Gefühl haben. Wir werden nicht alle auf dem gleichen Level Experten sein, aber wir alle müssen es mal ausprobiert haben. Wir alle müssen für uns selber einordnen können, was bedeutet das für unsere Rolle, für unser Unternehmen, für den Bereich, den wir verantworten. Und das, wie du es gerade sagst, ist ganz wichtig, selbst zu erfahren.
SPEAKER_01Sehr gut. Ein sehr schönes Schlusswort, Gregor. Es hat mir erneut sehr viel Spaß gemacht mit dir. Und wir waren jetzt ungefähr 15 Folgen dazwischen. Das heißt, in den nächsten nochmal 15 Folgen kommst du wieder. Und dann ist die AI-Apokalypse schon längst da. Sehr schön. Hat mir sehr viel Spaß gemacht, Gregor. Wir sehen uns ganz bald wieder. Bis dahin. Alles Gute. Mach's gut.
SPEAKER_00Danke dir, Philipp. Ciao, ciao.
SPEAKER_01Ciao, ciao.