# AI-Driven CTO Leadership and Organizational Strategy

**Podcast:** HMZE
**Published:** 2026-02-02

## Transcript

Die Brille ist super, kann man gleich 50 Euro mehr pro Stunde nehmen.
Herzlich willkommen zur allerersten Folge unserer neuen Staffel von HMZE Beyond Vibe Coding.
Der Podcast, in dem wir den AI-Hype beiseite schieben und schauen, was im Software Engineering wirklich passiert.
Ich bin Sebastian Heidemeyer zu Erben, CTO bei North.io.
Und ich bin André Neubauer, CTPO bei Trusted Shops.
Schön, dass ihr wieder da seid.
Für den Neustart haben wir uns direkt, wie sagt man so schön, einen Schwergewicht der deutschen Tech-Szene eingeladen.
Wenn man in Deutschland über Tech-Leadership, Organisationsstrukturen oder die Rolle des CTOs nachdenkt und ein bisschen bei LinkedIn unterwegs ist, kommt man an diesem Namen eigentlich nicht vorbei.
Wir haben heute Stefan Schmidt zu Gast.
Und wer Stefan nicht kennt, Stefan war selbst CTO, in unzähligen Startups mitgewirkt, viele Tech-Firmen von innen gesehen und ist heute, ich würde sagen, einer der bekanntesten CTO-Coaches des Landes.
Bei LinkedIn steht...
CTO-Coach, Europe-CTO-Coach number one.
Also er hilft Tech-Liedern täglich dabei, ihre Organisation aufs nächste Level zu bringen.
Und genau deshalb ist er der perfekte erste Gast für unseren neuen Podcast.
Denn die Rolle des CTOs verändert sich gerade fundamental.
Wenn es früher um Architektur und Skalierung ging, ändert sich gerade die Softwareentwicklung und auch die Rolle massiv.
Und die Frage ist, muss man jetzt nur noch Prompts optimieren, AI-Tooling entwickeln?
Oder wird menschliche Führung tatsächlich wichtiger denn je?
Darüber haben wir mit Stefan gesprochen und er hat ein paar abgefahrene Predictions gemacht.
Also lehnt euch zurück, genießt das Gespräch, viel Spaß.
Hello und welcome.
Unser heutiger Gast ist Stefan Schmidt.
Für die, die dich möglicherweise noch nicht kennen sollten von LinkedIn oder sonstigen Medien, stell dich doch einfach mal kurz vor für unsere Gäste hier, für unsere Hörer, sorry.
Soll es geben, dass Leute mich noch nicht kennen, trotz aller meiner Bemühungen, laut und penetrant zu sein.
Ja, also ich bin Stefan, habe vor 45 Jahren angefangen zu programmieren.
War lange Zeit.
Programmierer, Privatprogrammierer, war beruflich meistens, zumindest 25 Jahre Engineering Manager in diversesten Firmen.
Eigene Startups, andere Leute Startups, größere Firmen und bin seit ein paar Jahren CTO-Coach.
Vielen Dank, kurz und knapp.
Genau, dafür, dass es 45 Jahre umfasst und nicht nach Papa erzählt vom Krieg klingen sollte.
Ja, vielen Dank.
Wir freuen uns mega, dass du heute da bist.
So gleich die erste Episode Beyond Vibe Coding, unser Revamp von HMZE, vom Humanize Podcast.
Und da wollen wir immer grob generell über KI-Themen sprechen, beziehungsweise KI in der Softwareentwicklung und gehen immer so grob ein paar Punkte durch.
Und die erste Frage ist immer, wie arbeitest du derzeit mit?
KI in den Projekten, in denen du entwickelst, wie sieht dein Tech-Stack aus?
Also ich mache sehr viel, also als Coach mache ich praktisch kein KI, sondern erzähle den anderen Leuten, was sie machen sollten.
Privat mache ich aber sehr, sehr viel KI, weil ich schon wissen möchte, was geht und was geht nicht.
Mein TechStack sieht so aus, ich mache sehr viele kleine Tools für mich.
Weiß ich nicht, so etwas wie ein Tool, das mir meine statische Website auf das CDN hochlädt, weil ich nicht zufrieden bin mit dem official oder unofficial Client.
Also von diesen Sachen mache ich relativ viel.
Und ich mache ein relativ großes Projekt seit ein paar Monaten als Coaching-Plattform für das Management meiner Coaches.
Die haben irgendwie zugenommen und dann nimmt der administrative Aufwand auch zu.
Und dann habe ich irgendwann gesagt, ich brauche was, was alles maximal automatisiert.
Und das ist so der primäre Zweck des Ganzen, aber der sekundäre Zweck ist, dass ich eben lerne, was geht und was geht nicht.
Und da ist das Ziel bei diesem Projekt, das hat so um die 50.000 Zeilen Code, rauszufinden, wie weit komme ich denn, ohne auf den Code zu gucken, bis ich auf die Nase falle.
Das ist so der Scope.
Und da ist mein Stack Cloud Code.
Mit ein paar Plugins, auch mit, zum Beispiel jetzt gestern nochmal ausprobiert, LSP-Server, was ist deutlich nochmal besser.
Oder letzte Woche ausprobiert, glaube ich.
Das ist so ein Teil meines Stacks.
Und als Programmierensprache nehme ich immer Go.
Angefangen habe ich, weil alter Mann und einfach.
Go ist halt simpel, ist für alte Leute gemacht.
Und deswegen finde ich das super.
Rust war mir zu kompliziert.
Und jetzt stellt es sich aber glücklicherweise heraus, dass Go auch super für AI ist, aus verschiedensten Gründen.
Und deswegen ist es so, aktuell mein Tech-Stack, Cloud Code, manchmal Gemini nebendran oder Gemini oft nebendran, um zu kontrollieren, dass Cloud Code keine Bugs und keine Security-Probleme macht.
Also er kontrolliert immer die Commits mit und genau, und sonst Go.
Inwiefern hat sich das geändert, wenn ich mal so interessehalber fragen darf?
Also ich habe schon den Eindruck, dass da gerade gefühlt, nicht nur methodisch, sondern auch toolseitig ja immer noch enorm viel Bewegung ist.
Also ich bin ziemlich happy seit längerem.
Ich würde sagen, seit Sonne 3.7 und Claude bin ich recht zufrieden damit.
Die großen Sprünge, die andere Leute sehen, habe ich jetzt nicht so wahrgenommen.
Aber ja, also jetzt gerade zuletzt, was ich so ausprobiert habe, ist aus dieser...
Steve-Jerge Richtung Beats als Tool.
Das ist so ein Ticket-Management-System für die AI, also wo die AI selber sozusagen Tickets erzeugen kann, lokal und auch Git-kompatibel und so.
Da probiere ich sehr viel gerade rum.
Also ja, da ändert sich einiges, würde ich sagen.
Also für mich jedenfalls in Tools.
Toolchain also eher.
Okay, verstanden, verstanden, verstanden.
Wie sieht es aus mit Skills, Workflows, Ralph Wiggum Plugin?
Setzt du sowas ein?
Ne, das Plugin habe ich jetzt nicht, aber ich habe mit einem Tool, einem eigenen Tool, rum experimentiert oder experimentiert damit rum, wie man Prompts, also eine Prompt Library, beziehungsweise auch ein Prompt Executor, wie man Prompts zum Beispiel so zerlegt, dass sie kleineren Kontext haben.
Also ich habe sozusagen, das ist ganz lustig, das ist ein Tool, das hat einen Prompt drinnen und spuckt den stückweise aus, indem, wenn immer die AI sagt Next und dann spuckt das Tool aus und dann startet man das Tool einfach mit, sagt zur AI, starte das Tool und tu was, was das Tool sagt und dann funktioniert, also dann macht die AI was, dann sagt sie, jetzt bin ich fertig, dann sagt das Tool, ja, dann mach jetzt das.
Ich kam darauf vor einem Jahr oder so, hat ein Bekannter, Freund darauf gebracht, der benutzt sowas wie, das heißt Responsible Wide Coding, wo die LLM mit MCP gesteuert wird, wo das sozusagen ähnlich abläuft.
Da kann man im MCP-Server Workflows ablegen und Gates ablegen und dann fragt die ja immer den MCP-Server, was soll ich denn machen?
Fand ich ein bisschen zu kompliziert für meinen Zweck, aber da experimentiere ich drin rum, auch wegen der wegen der Probability, also wenn ich sage, so Read-Only-Prompts finden wir alle Bugs, dann ist es halt zufällig, wo er gerade wie tief reinguckt.
Und da was zu kreieren, dass die AI in eine Schleife zwingt.
Das ist aber nicht ganz einfach.
Und deswegen bin ich auch bei dem, mit Wiccan-Plugin oder sowas nicht ganz, also AIs kommen manchmal in so eine Doom-Loop.
Oder glauben halt, sie sind fertig.
Oder ja, also glauben in Anführungszeichen.
Ich weiß nicht, ob die AI was glaubt oder nicht.
Ich weiß nicht, ob meine Mitmenschen was glauben.
Von daher, ob die AI was glaubt.
Aber das, was du beschreibst, ist gar nicht so weit weg vom Rife-Wiggin-Plugin.
Also von diesem Endless-Loop.
Okay, verstanden.
Dann ist es also quasi zweierlei.
Das ist einmal Context-Management sozusagen.
Also Context-Length-Management.
Und eben dieses Lupen, also dass die AI nicht, weil sie scheinbar faul ist, so kommt das manchmal vor, wenn man damit arbeitet, zu früh aufhört, sondern dann wirklich weitermacht.
Ah, alles klar, interessant, okay.
Also bei dem zu früh aufhört, mein Prompting passt jetzt vielleicht nicht ganz, aber ich finde es wichtig.
Also du sagst es vor allem mit Planning.
Also jeder, glaube ich, macht mittlerweile ja sehr, sehr viel Planning.
Also Plan, Plan, Plan, also iterate on the plan, nicht.
Im Prompt.
Also nicht irgendwie eher was machen lassen und dann gegensteuern oder so.
Das ist nicht so gut, glaube ich, sondern sehr, sehr viel planen vorher.
Und was ich mittlerweile seit ein paar Wochen mache, ist unten drunter als Letztes sagen, ob die AI confident ist in dem Plan.
Also, are you confident that the plan works?
With the documentation in the code.
Dann guckt sie nochmal nach und dann sagt sie, ja, nee, an der Stelle bin ich eigentlich nicht confident.
Und dann bessert sie nochmal drei, vier Stellen nach und dann ist es auch deutlich besser.
Also, ja.
Schon zwei, drei coole Nuggets.
Ja, es ist tatsächlich, je mehr ich auch mich da rein vertiefe sozusagen, desto mehr stelle ich auch fest, dass ich viele Dinge, die ich früher auch in der Arbeit mit Entwicklern benutzt habe, die funktionieren so ähnlich auch bei einem LLM, weil das ist auch eine Standardfrage, die ich mir gestellt habe.
Eher dann an der Release-Seite sozusagen, aber tatsächlich auch, wenn es eine größere Solution-Architektur gab, die man besprochen hat, dann habe ich sowas auch gerne mal gefragt.
Ja, interessant.
Jetzt hast du ja gesagt, quasi viele Coaches, nicht viele, ja, Coaches, quasi kommen mehr dazu.
Hast du irgendwie so, also siehst du da einen Pattern, wie quasi das in deren Organisation vorangetrieben wird?
Also ist das da auch so extrem explorativ oder sind die eher quasi schnell festgelegt und versuchen es dann auf die Organisation umzulegen?
Meine Coaches kennen meine Meinung.
Ich glaube, meine Coaches kennen meine Meinung.
Ich halte da nie so hinterm Berg mit meinen Ansichten.
Ich glaube, wenn ich alle sage, meine ich die allermeisten meiner Coaches sind hinten dran.
Das ist aber kein großes Problem, weil die ganze Industrie hinten dran ist.
In meinem Maßstab, ich glaube, man könnte deutlich weiter sein, aber da alle hinten dran sind, ist es nicht so schlimm.
Aber ich würde die meisten meiner Coaches doch damit chaotisch beschreiben.
Also ich habe jetzt gerade ein paar von meinen Coaches haben Surveys gemacht, mal alle ihre Mitarbeiter gefragt, wie benutzt du denn, was machst du, was funktioniert, was funktioniert nicht, welche Tools benutzt du denn?
Und da wurden eigentlich alle überrascht von der Brandbreite an Tool-Usage und wie sie es nutzen.
Oder teilweise halt gar nicht nutzen.
Also ich habe auch immer natürlich den Punkt, gerade gestern wieder so einen Vortrag gehalten, ich hatte gern so kostenlose Vorträge in Unternehmen, um Entwickler auch zu verstehen.
Und die teilen sich dann in der Regel in so zwei Teile.
Der erste Teil ist, Stefan erzählt über AI, wie er das sieht.
Der zweite Teil ist, alle schlagen auf Stefan ein.
Das sind so die Teil 1, Teil 2.
Und da gibt es halt sehr, sehr viele Widerstände.
Und das sehe ich auch bei meinen Coaches.
Es gibt so viele kleine gallische Dörfer in den Organisationen, die dem AI-Ansturm sich widersetzen und ausharren.
Aber nicht geplant, nicht strukturiert, das sind die, glaube ich, alle noch nicht.
Also es gibt so zum Teil, dass sie den Chief AI Officer einführen oder solche Sachen, aber in weiten Teilen würde ich eher sagen, viel Druck.
wenig organisiert.
Was meinst du mit Druck?
Also Druck vom Business?
Macht man jetzt schneller?
Es müsste schneller gehen mit KI?
Ja.
Alles klar.
Ich habe für später eigentlich eine Frage aufgehoben, aber dann würde ich die vielleicht vorziehen.
Also für mich, also ich hatte mir notiert, Hast du einen Tipp für Tech-Manager, wie sie ein Schiff zu AI in Organisationen hinbekommen?
Also vor allen Dingen vor dem Hintergrund, dass das, was du ja gerade erläutert hast, so ein bisschen so Adoption Curve, also quasi First Mover, was gar nicht, Early Followers, nee, wie ging das?
First Mover, Early, ich glaube es sind vier Zustände.
Early Adopters, Early Majority.
Genau, am Ende kommen die Laggards, ne?
Dann Early Majority, Late Majority und dann die Laggards.
Genau, okay, also fünf Phasen.
Und irgendwann mal, ich glaube, Simon Sinek hat das, gibt es ein gutes Video zu, irgendwie erklärt hat, quasi warum halt so Innovation und Organisation halt auch gekillt wird.
Also quasi, weil du halt quasi die Menge an Leute, die halt tendenziell nicht dafür ist, ist halt größer als die Leute, die halt davon begeistert ist.
Nichtsdestotrotz, gibt es irgendwas, wo du sagen würdest, das ist quasi Secret Source, das müsste man machen?
Also sammelt man quasi die Early Adapters oder First Movers ein und separiert die, damit die wenigstens das nutzen?
Wild Guessing, hättest du da was?
Meine Gedanken sind so ein bisschen, wir haben ja auch ein bisschen gemeinsame Geschichte.
Ich sehe das so ein bisschen wie halt auch am Ende wie mit Agile.
Viele machen mit und manche wollen nicht.
Und das ist wahrscheinlich genau das Gleiche mit AI.
Daran muss man sich potenziell gewöhnen und muss sich überlegen, was machen wir mit den Leuten, die nicht mitwollen.
Ich glaube, um das zu verkleinern, diese Gruppe, muss man den Leuten einen Weg aufzeigen in eine goldene Zukunft, in der sie einen Platz haben.
Und das ist auch eine Managementaufgabe, eine Geschichte zu strukturieren und zu erzählen.
Ich stelle mir das immer so vor, wenn man zum Beispiel Moses nimmt oder sowas, ich weiß, ein komischer Vergleich, aber da ist jemand und sagt, okay, jetzt lass uns mal alle in die Wüste gehen.
Dann stelle ich mir vor, wenn das so war, stelle ich mir vor, dass die Leute nicht happy waren.
Dann sagt man dann, okay, jetzt gehen wir aber in die Wüste und dann da ist das gelobte Land.
Und da müssen wir halt hin und ich bin derjenige, an den ihr glauben müsst und ich bringe euch da hin und alles ist gut.
So ähnlich ist es, glaube ich, schon auch mit AI.
Also du musst den Leuten, glaube ich, das ist das Wichtigste, eine goldene Zukunft zeigen, in der sie sein wollen.
Und dann kannst du, glaube ich, die Anzahl, die zurückbleiben, minimieren.
Also man braucht auch Karotte, nicht nur Stick.
Man braucht primär eine Karotte, glaube ich.
Ich bin Karotten-Fan.
Aber ich trete auch den Leggards in den Hintern, also wenn es sein muss.
Ich glaube, man braucht beides, aber ich würde jetzt nicht mit Stick anfangen.
Generell, was ich aber raten würde, ist, ich würde jedem raten, jedem Engineering Leader, einfach mal zu gucken und die Leute zu fragen, was denken sie über AI, eine Befragung zu machen, in person oder ...
Im One-on-One, wenn sie sowas machen, machen zu wenige Leute.
Und zu verstehen, was ist eigentlich der aktuelle wirkliche Status Quo an der Sache und was glauben die Leute, damit würde ich anfangen.
Absolut.
Mit der Erhebung des Status Quo, um erstmal zu wissen, wo man steht, muss man immer anfangen.
Und was du beschreibst, ist ja auch, wie...
Führung im Prinzip in Wissensarbeit funktioniert.
Dieses Modell Transformational Leadership, wo man eben sagt, man hat eben diesen Everest und dann bespricht man mit den Leuten, wie man diesen Everest besteigen kann, bezieht sie in den Plan mit ein, beziehungsweise erstellt den Plan mit denen und geht dann mit ihnen den Weg.
Und genau, das ist ja das, was du auch beschreibst.
Und am Ende, genau, du hast gerade kurz was fallen gelassen, was ich einfach nur kurz nochmal kommentieren möchte.
One-on-ones.
Ich habe schon, bevor ich Manager wurde, mal so einen Podcast gehört, managertools.com und das wichtigste Manager-Tool überhaupt sind One-on-Ones.
Also kann ich nur zu aufrufen, wer keine regelmäßigen One-on-Ones macht, wenn man ein kleines Team hat, auf jeden Fall weekly.
Wenn man ein größeres hat, dann schafft man es nicht mit allen weekly, okay, aber doch regelmäßig, damit man einfach auf der Beziehungsebene arbeiten kann, damit man aligned ist und feststellen kann, wenn man nicht aligned ist, möglichst früh und nicht, dass die Schere irgendwann so weit aufklappt, dass man...
gar nicht mehr zusammenfindet oder es nur noch unter großen Schmerzen passiert.
Das nur kurz am Rande.
Vielleicht nochmal kurz zu den sozusagen verschiedenen Gruppen.
Ich habe neulich einen Podcast gehört mit Markus Andrezak und das war auch extrem interessant, auch mit einem Agenturmenschen, der auch schon sehr lange Agent-Decoding beziehungsweise AI-Assisted Coding, wie auch immer, macht.
Der erlebt auch viele Organisationen und hat so ein paar Zahlen genannt oder Kategorien aufgemacht von Leuten, die schon voll dabei sind, irgendwie Agentic nutzen, den neuesten Scheiß nutzen, dann Leute, die JGBT-Fenster offen haben oder vielleicht irgendwie Copilot nutzen oder so und dann Leute, die eigentlich gar nichts machen oder halt wirklich nur mal ab und zu irgendwie JGBT oder Gemini was fragen.
Wie würdest du sagen, sind da so aus deiner Erfahrung die Wie ist da die prozentuale Verteilung auf diese drei Gruppen bezogen?
Das hängt immer sehr stark von der Organisation ab.
Mein mentales Modell ist so ein bisschen das Startup-Modell.
Das heißt, Startups haben nichts zu verlieren, deswegen haben sie einen hohen Risk-Appetite.
Und große Unternehmen, die viel zu verlieren haben, probieren halt Sachen nicht aus.
Das gilt jetzt auch für den Entwickler.
Das heißt, der Entwickler, der nichts zu verlieren hat, macht mehr und der Entwickler, der viel zu verlieren hat, macht wenig.
Also der Senior-Entwickler, der 30.000 Euro pro Jahr mehr verdient als die anderen, weil er mehr kann als die anderen, hat nicht das größte Interesse, seinen Wettbewerbsvorteil durch AI einzuebnen.
Das ist so ein bisschen...
Sehr ähnlich finde ich eben zu Startups.
Mit anderen Worten, Juniors ziehen da gerade, zumindest was das anbelangt, an den Seniors möglicherweise vorbei oder an vielen.
Und insofern hängt es so ein bisschen von der prozentualen Verteilung in der Organisation wahrscheinlich ab, wie stark die Leute das schon nutzen.
Ich brauche mehr Mut, wenn ich mehr zu verlieren habe.
Könnte man aber positiv formulieren, natürlich auch total als Chance und sagen, Karten werden neu gemischt.
Also je nachdem, wie welchen Faktor Software oder Softwareprodukte spielen in deinem Business, kann das natürlich dann jetzt auf einmal auch ein competitive advantage sein.
quasi ein bisschen größeren Risk-Appetite.
Aber ich sehe auch, also ich glaube, hängt total am Kontext.
Ich habe auch so einen kleinen AI-Newsletter, den keiner liest, aber der heißt quasi Tabula Rasa, weil ich auch glaube, dass die Karten neu gemischt werden, in allen Bereichen.
Jetzt hatte Sebastian gerade ja schon erwähnt, so Podcasts, du hast ja neulich auch einen Podcast gegeben, jetzt muss ich überlegen, Tech Journal heißt das?
Tech Journal, glaube ich.
Tech Lead Journal.
Meine Güte.
Das, was bei mir da hängen geblieben ist, ist quasi Coder und Creator.
Die Unterscheidung fand ich super.
Vielleicht kannst du da nochmal ein bisschen drauf eingehen, wie du das siehst, wie du das unterscheidest.
Erstmal ist es natürlich super, dass jetzt Leute mich aus anderen Podcasts zitieren.
Das ist so ein bisschen wie im Fernsehen.
Sie haben zuletzt im Starren gesagt oder so.
Also das ist schon mal ziemlich cool.
Wir bereiten uns auf unsere Gäste vor, Stefan.
Auch super.
Coder und Creator.
Ich dachte 44 Jahre lang, ich bin Coder.
War sehr stark in meiner Identität sozusagen.
Und dann habe ich Ende letzten Jahres herausgefunden, ich bin gar kein Coder.
Ich bin Creator.
Was ist der Unterschied?
Der Unterschied ist für mich in meiner, in dieser Definition, der Creator möchte Sachen erschaffen und nützt dazu das bestmögliche Werkzeug, um diese Sache zu erschaffen.
Das heißt für mich, ich bin in diese ganze Industrie reingerutscht, als ich ein Kind war, weil ich Videospielideen in meinem Kopf hatte und die wollte ich spielen.
Und der Weg dazu, meine Ideen zu spielen, war programmieren zu lernen.
Am Ende waren die Sachen, die ich programmiert habe, nicht so ganz so geil wie die Sachen, die ich im Kopf hatte, aber es ist halt so ein kleiner Skillgap.
Aber das ist sozusagen für mich der Creator.
Und das Tool ist Werkzeug zum Erschaffen.
Und der Coder, würde ich sagen, ist eher jemand, dem das Produkt nicht sonderlich interessiert oder nicht so sehr interessiert, was hintenbei rauskommt, sondern den der Code primär interessiert.
Und der sich vielleicht sogar mit der Programmiersprache identifiziert.
Also der sagt, ich bin Java-Entwickler oder ich bin Go-Entwickler oder sowas.
Also der sozusagen seine eigene Identität nicht nur ans Coden hängt, sondern sogar noch an der Programmiersprache hängt.
Und natürlich ist es so ein Spektrum.
Also ja, ich bin ja auch vielleicht 10% Coder oder vielleicht bin ich auch 30% Coder, ich programmiere ja auch gern.
Oder gucke gern Code an oder löse gern.
freue mich, wenn ich irgendwie eine Struktur geschaffen habe mit Funktionen und Currying und so weiter und so fort.
Das erfreut mich ja auch irgendwie innerlich.
Aber primär bin ich eben ein Creator.
Das heißt, ich will Sachen schaffen.
Und die Programmiersprache ist mir auch nicht ganz so wichtig.
Ich habe halt irgendwie in den letzten Jahren auch über die Zeit über 20 Programmiersprachen benutzt.
Dann wechsle die ich halt, wenn der andere kommt oder so.
Das ist mir jetzt nicht so wichtig.
Und ich glaube, der Creator in diesem AI-Transformation hat wenig Probleme und wird AI begrüßen, als ein mächtigeres Werkzeug Sachen zu schaffen.
Und der Coder wird Schwierigkeiten haben, aus meiner Sicht, und das ist eine Prediction, ich kann falsch liegen, aber wird Schwierigkeiten haben, weil das Schreiben von Code durch Menschen zurückgehen wird.
Das ist so meine Aufteilung und wie ich die Welt mittlerweile sehe.
Und ich glaube, dies erklärt, dass manche Leute keine großen Probleme damit haben und manche Leute große Probleme damit haben.
Ich fand es eine der Thesen, die mich jetzt mal wieder seit langem gecatcht haben und viel darüber nachdenke.
Und einen der Gedanken, die ich dazu hatte, ist, wir haben wirklich Jahrzehnte damit verbracht, das Gegenteil zu hypen.
Also quasi, wenn ich so überlege, auch in unserer gemeinsamen Vergangenheit quasi Clean-Code-Videos geteilt und quasi überlege, wie Software-Design noch besser sein kann.
Und ich glaube gar nicht, ich will damit gar nicht sagen, dass es jetzt irrelevant ist.
Aber wenn das so stimmt und ja, das ist jetzt erstmal eine Hypothese, aber ich finde die gar nicht so verkehrt, dann sehen wir gerade massiven Shift.
Also das, was unter der Haube passiert ist.
im Zweifelsfall weniger wichtig, weil sich jemand anders drum kümmert.
Jetzt wird es dünnes Eis, aber ich finde den Gedanken eigentlich ganz cool.
Auch um sich selbst zu challengen, was ist man denn?
Und was muss ich vielleicht im Zweifelsfall auch werden?
Ich finde in dem Zusammenhang auch eine Aussage aus dem Tech Lead Journal Podcast ganz spannend, auf der ich auch lange rumgedacht habe, die du gemacht hast, nämlich was daran anschließt eigentlich, dass du die Prediction machst, dass Code verschwinden wird im Laufe der Zeit.
Die Herleitung fand ich auch super.
Also er musste erst mal mich da sozusagen dieser Logikkette darauf einlassen.
Aber du hast ja gesagt, es gab die Entwicklung, erst hat man Maschinencode genutzt direkt, dann gab es Assembler, dann E-Hochsprachen.
Und immer gab es mehr Abstraktion.
Man hat sozusagen eine Ebene darunter verlassen und die auch tatsächlich vergessen.
Trendfolgen könnte man jetzt sagen, irgendwann gibt es dann einfach gar nicht mehr den Quellcode, also dieses sozusagen Zwischenstück, sondern es gibt direktes Kompilat.
Es gibt natürlich Markdown-Files, System-Prompt-Tooling etc.
Und die KI generiert einfach nur aus diesen Rahmenbedingungen das fertige Kompilat.
Ist das so das, was du damit gemeint hast oder ging es sogar noch darüber hinaus?
Also am Ende gehe ich darüber hinaus.
Ich mache ja, ich hatte jetzt auf der Code Talks diesen Vortrag, wo ich glaube, dass es hingeht.
Der Kern ist, AI ist nicht Software und der Kern dieser Aussage ist, wir haben jetzt die letzten 50 Jahre.
Software als dominantes Standardwerkzeug zum Lösen von Problemen verwendet.
Und wir werden in Zukunft AI als Standardwerkzeug zum Lösen von Problemen nehmen und nicht mehr Software.
Also AI im Sinne von, ich weiß nicht, wie es aussieht, aber potenziell trainierte Modelle oder ich weiß nicht, welche Strukturen, aber nicht über das Hilfsmittel AI erzeugt Code, der dann läuft.
Da, glaube ich, geht es hin.
Wann, weiß ich nicht.
Ich glaube, da wird es hingehen.
Und diese Code-Generierung, die wir aktuell sehen, sehe ich eher transitional.
Aber ja, wir bewegen uns in der Kette nach oben, würde ich mal sagen.
Auch, wo ich vielleicht nochmal darauf hinweisen möchte, immer mit der Herausforderung des Kontrollverlusts.
Also ich hatte einen Freund, der hat Maschinencode, also Spiele in Maschinencode geschrieben.
Und lustiger, der hat die runtergeschrieben auf Papier und dann abgetippt und dann haben die funktioniert.
Das ist ja wie in die Matrix gucken.
Habe ich nicht gemacht.
Ich habe irgendwie mit Assembler angefangen und dann schon Maschinencode auch gelernt, weil Self-Modifying-Code und so und Ob-Codes-Tauschen.
Aber von da zum Sprung von C hat man natürlich einen gewissen Kontrollverlust, wie ich jetzt diese Schleife mit welchen Registern mache und so weiter.
Und dann von C zum Beispiel zu Java, da fiel mir das eben auch sehr, sehr stark auf.
Da gibt es den Kontrollverlust zum Thema Memory Management.
Vorher, und das war ein sehr großer Punkt gegen Java aus Richtung von C++ oder C, zu sagen, ich habe keine Kontrolle mehr, was eigentlich mit dem Speicher passiert.
Und früher haben auch viele Organisationen in der Frühphase von Java damit gekämpft, dass der Garbage Collector plötzlich zur blöden Zeit lief, weil der Garbage Collector war halt auch blöde.
Und dann gab es so zwei Sekunden, zehn Sekunden, 30 Sekunden Stillstand auf der Webseite.
Also dieser Kontrollverlust war auch real, ist aber dann halt eben weggegangen und die Leute haben den auch akzeptiert und haben dann akzeptiert, dass sie diese Kontrolle gar nicht brauchen weitestgehend.
Es gibt immer Nischen, die anders sind, aber weitestgehend brauchen und auch nicht wollen.
Und ich glaube, diesen Schritt sehen wir halt ähnlich wieder, also mit AI.
Das heißt, es gibt einen Kontrollverlust.
Ich weiß nicht mehr genau, welcher Code wie ausgeführt wird.
Das führt zu Problemen auch, gerade weil die Erinnerung nicht so gut ist.
Wird aber, glaube ich, den gleichen Weg gehen wie in Java, dass die Leute halt kein Memory-Management mehr machen wollen weitestgehend oder sowas.
Ja, jetzt bin ich glaube ich nochmal ein Stück weiter mit auf diese Reise gegangen, gedanklich, weil ich erst noch überlegt habe, okay gut, wenn man jetzt dieses DMD-Files und das Tooling hat und so, dann man will ja trotzdem noch das Tooling, also man will ja trotzdem noch irgendwie Tests haben, die man auch selber verstehen kann und irgendwie Deployment-Pipelines, wo halt wiederkehrende Artefakte sind, damit man aus diesem rein probabilistischen rauskommt.
Aber auch das alles kann man ja wiederum durch...
wie auch immer geartete Artefakte ersetzen, ob das jetzt irgendwie Cucumber-Tests sind, die dann einfach vom AI-Agent ausgeführt werden oder was auch immer.
Jetzt habe ich es verstanden.
Dann ist bei mir eigentlich nur noch der Punkt, dass du sprachst, glaube ich, in dem Podcast auch davon, Microservices durch KI zu ersetzen, dass diese probabilistischen algorithmischen Lösungen ja meist ineffizienter sind als, also im Sinne von rein jetzt bei der Runtime, ineffizienter als ein fertiges Kompilat.
Also geht da nicht dann was verloren?
Beziehungsweise was war die Intention, als du das gesagt hast in dem Podcast?
Am Ende muss ich den Code nicht schreiben.
Also wenn ich jetzt irgendwie einen Service habe, der, ich sage jetzt mal, ich weiß nicht, aber ich habe jetzt einen Service, der User-Daten speichert oder Kundendaten speichert, Customer, Microservice oder sowas, dann muss ich halt, da kommen da irgendwie Daten rein über eine Schnittstelle und dann müssen die in der Datenbank landen.
Und dann kann ich mir überlegen, dann schreibe ich da entweder Code dazu oder ich könnte halt auch eine AI trainieren, die das macht.
Dann brauche ich da kein Code mehr schreiben.
Und wenn die AI möglicherweise gut gemacht ist, ich weiß aber nicht.
was gut bedeutet, dann ist sie halt flexibler und kann leichter auf Edge-Cases eingehen, kann sich leichter entwickeln.
Ich muss vielleicht gar nichts machen, ohne dass sie sich entwickelt oder die lernt über die Daten oder ich muss es potenziell nicht mehr anfassen.
Ich mache das Ding und dann macht es das.
Bei Code muss ich das halt anfassen.
Das wäre so für mich der Vorteil für eine Firma und weswegen die Firma das potenziell macht.
Zu der Effizienz, finde ich, fällt mir bloß immer ein, naja, Wenn ich es in Maschinencode schreibe, dann kann ich potenziell ganz Facebook auf einem Server betreiben.
Und wenn ich das halt in Python mache, dann brauche ich halt 1000 Server.
Meine Kunden haben halt teilweise diese Situation, die haben hohe Kosten bei einem Cloud-Anbieter und benutzen halt Python.
Dann sage ich, ja, mach das in Go, kannst du dann...
also Ingress, Outgress und so weiter, alles mal außen vor, aber sage ich mal übertrieben gesagt, machst du ein Go, hast du doppelte Effizienz, halbe Kosten.
Interessiert die aber nicht.
Also dieses Effizientere, wenn Effizienz wirklich so stark wäre, und jetzt kann man sich nochmal über die Größenordnung natürlich unterhalten und abwärts wirklich relevant ist, aber wenn es so relevant ist, würden alle Leute potenziell Rust nehmen, weil es halt einfach irgendwie am wenigsten Speicher braucht, mit Abstand, am schnellsten ist, mit Abstand, so, und die Leute benutzen halt Python.
Ich kann mir vorstellen, das ist ein Grund, warum man das quasi gerade nicht hören will, ist, dass viele Firmen nicht auf quasi Optimierung schauen, sondern auf Capabilities, also neue Capabilities.
Also man könnte ja auch sagen, lass uns den Umsatz verdoppeln oder verzehnfachen, verhundertfachen.
Dann sind die Serverkosten im Zweifelsfall ein Rundungsfehler.
Also lass uns halt für die nächsten Service eine andere Sprache nutzen.
Du hast aber auch das in dem anderen Podcast erwähnt.
Ich frage mich, gibt es irgendwas, wenn man das jetzt so als Target-State mal stehen lässt, gibt es irgendwas, was man heute schon an der Architektur anpassen muss, anpassen kann, um sich auf dieses Zeitalter vorzubereiten?
Also Architektur ist ja eher träge.
Das ist ja nichts, was ich heute ändere und morgen einen Impact hatte.
Aber ich frage mich, wir werden ja über viele...
Jahre, vielleicht Jahrzehnte, dann irgendwie so Mixed Environments sehen.
Wo vielleicht doch nicht, keine Ahnung, wenn man das halt irgendwie schnell alles replacen kann.
Jetzt kommen wir irgendwie so, ich habe gerade so einen Ralf-Begin-Loop im Kopf.
Aber gibt es irgendwas, wo du sagen würdest, naja, Architektur, aus einer Architektursicht, würde man heute das ändern müssen, um auf diesen Pfad zu kommen?
Etwas, was vielleicht nicht dazu passt, aber doch dazu passt.
Ich würde immer einen Studierenden einen Studenten oder Studentin einstellen, also vielleicht auch einen Mitarbeiter, aber mindestens jemanden, der sich mit diesem Thema beschäftigt und Sachen ausprobiert und sagt, okay, jetzt der Stefan hat die Idee, wir könnten den Customer Service durch eine AI ersetzen, durch ein Prompting oder durch ein Training oder was weiß ich was.
Ich glaube, es ist wichtig zu verstehen, was geht und was geht halt nicht.
Ich sage ja nicht, dass alles geht.
Ich glaube, es ist wichtig zu verstehen, generell, was ist denn technisch möglich und wo fallen wir auf die Nase, diese Grenzschicht zu erkennen und zu wissen.
Das ist, glaube ich, das Erste, was ich machen würde, was ich immer machen würde.
Und das Zweite, was so ein bisschen ein Denkmodell bei mir ist, ist in der Transition, ist ein Service human-owned oder ist er AI-owned?
Also guckt primär der Mensch drauf und benutzt Autocompletion Code Generation, aber der Mensch owned das oder owned diesen Service der AI.
Also ich habe primär Generierung, ich gucke vielleicht nicht mehr in allen Code rein.
Und das für seine bisherigen, für Microservices oder Module oder Server oder sowas zu klassifizieren.
Und es kann ja sein, dass man mit allem anfängt und sagt, alle sind human owned.
Und dann muss man aber eben gucken, wie komme ich da hin zu AI owned.
Zum Beispiel, indem ich eben mehr Guardrails einführe.
Oder wenn man die Rolle 20 Jahre zurück macht, dann war vor 20 Jahren, gab es einen Head of QA.
Und dann hat man vor einem Release den Head of QA gefragt, können wir releasen oder können wir nicht releasen?
Und dann hat der gesagt, ja, alle Tests laufen durch oder der läuft nicht, aber sonst ist alles gut.
Ich gebe eine Release-Empfehlung.
So, doofes Wort.
Kann man sich nicht vorstellen, war aber so.
Und da hat aber niemand in den Code reingeguckt für diese Release-Empfehlung.
Und ich denke, das muss man dann, wenn man AI-owned Services hat, auch zu dem Modus kommen.
Man muss zuversichtlich, also berechtigt zuversichtlich sein können, etwas zu releasen.
Indem ich zum Beispiel mir die Tests angucke, die laufen, oder indem ich eine AI frage, oder indem...
weiß ich nicht, was auch immer ich mache.
Aber ich brauche ein anderes Setup für AI-owned-Code als für Human-owned-Code.
Und das wäre für mich so ein Schritt, wo man versucht, vielleicht hinzukommen oder Sachen zu ersetzen, die vielleicht nicht Mission-Critical sind oder solche Sachen.
Ich würde nicht mit Mission-Critical anfangen, mit High-Risk-Sachen, nicht mit Mission-Critical kombinieren.
Das wäre für mich so ein Schritt.
Und dann ist, glaube ich, der nächste Schritt halt, wie kann ich die Code, der da läuft und AI generiert ist, durch AI ersetzen oder so.
Der erste Schritt wäre für mich diese Unterscheidung Human-Owned und AI-Owned mit unterschiedlichen Guardrails und Randbedingungen.
Hast du da ein paar Guardrails-Randbedingungen, die du dafür für zwingend erforderlich hältst oder Band, die besonders wichtig sind?
Was jetzt, glaube ich, aktuell ist es für mich eine hohe Testabdeckung und ich gucke in die Tests rein, ob die das tun, was sie sollen, stichprobenartig.
Ich habe das in der Schule schon nicht verstanden, richtig?
Leistungskurs Mathe habe ich jetzt nicht ganz verstanden, doch das habe ich verstanden, aber mit stochastischen Proben und so.
Er hat nicht ganz verstanden, hat mir dann mal ein sehr intelligenter Head of QA versucht zu erklären, wie viel man prüfen muss, damit man eine belastbare Ausgabe findet.
Habe ich auch nicht verstanden.
Aber irgendwas in der Richtung, glaube ich, ist sinnvoll.
Vielleicht lernen jetzt Leute mehr, wie es geht.
Das ist das eine.
Es geht aber möglicherweise jetzt eben auch dieser Trend.
in Richtung Spec-Driven Development und dann kann man sich vielleicht auch die Specs angucken und die AI fragen, ob die alle eingehalten sind oder durch Tools sich ein Tool schreiben lassen von der AI, die das prüft.
Manchmal ist es gut, die AI nicht was prüfen zu lassen, sondern die AI ein Tool schreiben zu lassen, was was tut.
Das ist deterministischer und repeatable.
Aber sowas zum Beispiel zu machen oder generell auch mal die AI zu fragen, ist die Testabdeckung gut oder so?
Oder wo ist die eigentlich schlecht?
Oder sind die Tests gut oder sind die schlecht?
AI ist interessanterweise relativ selbstkritisch über das, was sie da getan hat.
Aber das wäre Testcoverage, ein Testbericht von der AI.
stichproblematische Tests zu gucken, um dann sich eine Zuversichtlichkeit zu gewinnen, zu sagen, ja, okay, wenn das alles so ist, dann wird das auch laufen.
Bei Spec-Driven bin ich mir aktuell nicht ganz so sicher, weil es sehr, sehr stark gehypt wird.
Ich sehe auch den Benefit, bin mir aber nicht ganz sicher, ob das dann am Ende ein Produktivitätsgewinn ist.
Also wenn ich super, super viele Specs selber alle Edge-Cases verwenden muss und nicht die AI, die Edge-Cases verwalten lasse, sozusagen, also zu extrapolieren lasse, dann weiß ich nicht, ob ich Zeit spare oder ob ich wirklich effizienter werde.
Da bin ich mir nicht ganz so sicher.
Das ist auch mit meinem Tool, was ich vorher angesprochen habe, das die AI steuert.
Da ist mir auch nicht ganz klar, wie viel muss ich in den Prompt reinschreiben, um die AI zu zwingen, das zu tun, was sie soll und wie viel...
Zügel muss ich loslassen, damit ich die Intelligenz der AI nutzen kann.
Und das ist so ein bisschen bei dem Thema Spectre auch.
Wie detailliert muss ich eigentlich werden?
Und die Befürchtung ist, wenn ich sehr detailliert werden muss, kann ich auch gleich Code schreiben.
Also, ja.
Ja, ich glaube, das ist genau die Krux, weil man, sagen wir mal, die große Herausforderung dabei, in meinen Augen, ist ja am Ende den Kontext mitzugeben, den die AI braucht, um das Problem zu lösen.
Dass man genau weiß, also dass man möglichst genau die Intention, also was ist eigentlich intendiert dahinter, an die AI übergeben kann.
Und dafür ist der Planning Mode bei Cloud Code beispielsweise oder Antigravity nutze ich auch super, dass man sagt, hier, das ist meine Idee, das und das sind die groben Rahmenbedingungen, stell mir Fragen und frag mich, was du wissen musst.
Und dann kommt da halt irgendwie so eine Spec raus, die ich auch gerne in so ein MD-Dokument packe, weil ich feststelle, also in einer Legacy-Application, die ich gerade tief reingucke, da gibt es nicht so viel Dokumentation.
Deswegen freue ich mich über alles an Dokumentation, was die KI da erzeugt.
Aber grundsätzlich ist es ja auch nur quasi so lange relevant, bis die Features implementiert sind sozusagen und die Tests implementiert sind, laufen etc.
Und man dann über die CI das deployed.
Und dann sind im Prinzip die Tests und auch die KI ausreichend, um sich alle Fragen relativ schnell beantworten zu können, ohne dass man wirklich sich da tief durch den Code fräsen muss.
Wie sieht denn in dem Zusammenhang nicht funktionale Anforderungen?
Weil für mich ist die ganze Trend und Hype um quasi Spec-Driven-Developer, du hast es gerade gesagt, Stefan, sehr stark alles fokussiert aufs Fachliche.
Ich hätte bei Guardrails, wäre mein Take noch viel stärker Nichtfachlichkeit, weil das tatsächlich nicht so gut abgedeckt werden kann.
Auch einfach dadurch, dass dieses Setup, dieses Tool oder dieses Tooling halt von Leuten genutzt wird, die mitunter nicht fachliche, nicht funktionale, nicht fachliche Anforderungen halt einfach nicht gut verstehen.
Ich hätte da tatsächlich viel mehr Schwergewicht drauf gelegt.
Also ich denke, Aktuell bin ich immer noch der Meinung, dass der beste AI-Bediener ein Softwareentwickler ist.
Aus verschiedensten Gründen.
Erstens, weil ich so ein bisschen, also ich habe bei mir jedenfalls so das Gefühl, dass ich manchmal weiß, wenn ich jetzt den Prompt so schreibe, weiß ich, wie es schief geht.
Also, weil das ist so ein bisschen wie ein Juniorentwickler, wenn ich dem das so sage, weiß ich, dass es so schief geht.
Und da gibt es sehr viele Parallelen aus meiner Sicht.
Und dann prompt die es halt anders oder sagt, bitte da drauf achten, weil im Plan, weil es sonst eben halt schief geht.
Das ist so das eine.
Und das ist halt dann auch manchmal eben an den nicht funktionalen Anforderungen.
Wie man es löst, weiß ich nicht, aber ich habe schon öfter auch mit der erheiternden Diskussion, Wie könnte man jetzt potenziell das schneller machen oder so?
Die Startup-Zeit verringern und so.
Und dann schlägt es Sachen vor, die sind dann meistens auch ziemlich gut.
Und dann schlägt es halt Sachen vor, die halte ich für over-engineert.
Also das ist dann eher so dieses Senior-Entwickler-Problem oder das Pseudo-Senior-Entwickler-Problem.
Der echte Senior-Entwickler würde nie over-engineert.
Aber potenziell der nicht so, also in meinem.
Kategorie-Modell, was ich richtig finde, was andere Leute verstehen.
Ich will auch gar nicht sagen, dass es allgemein gültig ist, mein Modell, aber wie ich die Welt sehe.
Und dann fängt die AI auch an, Over-Engineering zu machen.
Und dann will sie irgendwelche Sachen machen, dann sage ich, ja, weiß nicht, finde ich nicht so gut.
Dann sagt die AI, ja, ist vielleicht auch over-engineert.
Die stimmt mir dann immer zu, mach mal positiv, wenn einem einer recht gibt.
Aber das mache ich schon und das hat auch relativ erfolgreich funktioniert, auch beim Thema Security.
Ich weiß nicht genau, also wenn ich wählen könnte zwischen der AI Security und einem Security Researcher, jemand sagt, mach das oder das, ich bezahle beides, würde ich wahrscheinlich einen Security Researcher nehmen, um mich sicherer zu fühlen.
Aber das ist natürlich dann auch immer so ein Vertrauensthema.
Das ist halt ganz, ganz groß.
AI ist neu, wir haben kein Vertrauen, wenn AI...
20 Jahre kein Atomkraftwerk in die Luft pflegt, obwohl der Code AI ist, dann sagen alle, ja, wird schon nicht schief gehen.
Also es hat halt auch immer eine große, es hat immer auch ein großes Vertrauensthema.
Die Leute hatten wahrscheinlich auch Angst vorm Auto oder so.
Und dann ist das Auto halt nicht in die Luft geflogen, der Motor mit der Verbrennung und dem ganzen Ding oder bei einer Dampfmasch, es ist ja manchmal in die Luft geflogen, ein Dampflok oder so.
Aber meistens sind sie nicht in die Luft geflogen und dann haben sie gesagt, dann fahre ich halt Zug.
Und so, glaube ich, ist es halt am Ende dann auch mit AI und auch mit dem Thema Security oder nicht funktionale Anforderungen zu sagen, bitte achte auf Security Performance.
Weiß ich nicht.
Und dann macht sie das.
Ja, genau.
Brauchst du mehr Handholding.
Und wenn du kein Software-Engineer bist, dann kann es sein, dass du leicht ins Knie schießt.
Ja, genau.
Würde ich 100% bestätigen.
Ist dann bei mir eigentlich auch immer Bestandteil.
der PRD sozusagen, wenn einer entsteht, dass ich das, was ich im Kopf habe, mit reingebe und dann wiederum ergänzt die KI auch richtig gut.
Wo AI halt sehr, sehr stark ist, ist in breitem Wissen.
Also die AI weiß, also da auch wieder in Anführungszeichen, ich habe ein paar Jahre Philosophie studiert, deswegen weiß ich noch nicht genau, Intelligenz und Weiß und so sind also schwierige Worte.
Die KI weiß, wie das Adressformat in China ist, während der Entwickler weiß das halt nicht.
Also dieses offensichtliche breite Wissen, da ist die AI halt super gut.
Und in dem schmalen Wissen, was nur in deinem Unternehmen existiert, ist die AI halt relativ schlecht, wenn du es ihr nicht sagst.
Und da stellen halt, glaube ich, hauptsächlich sehr viele Produktmanager fest, dass, Entschuldigung an alle Produktmanager, aber dass wie viele Entwickler als im Kopf der Entwickler war und den Gap zwischen Ticket und Code schließt.
Es ist halt super, super viel implizites Wissen und andere Sachen in den Köpfen der Entwickler.
Also Security oder mach da keinen Scheiß oder sowas und so.
Dann lief das dann doch, auch wenn sie Produktmanager beschweren über Entwickler, aber dann doch relativ smooth, weil der Entwickler doch sehr viel da ausgeglichen hat auch an nicht funktionalen Sachen und die AI das halt aktuell nicht macht.
Besonder Menschenverstand.
Was ich in dem Zusammenhang immer, also mein Concern an dem Ganzen ist es halt, wir sind relativ gut da drin, halt einfach Fachlichkeiten zu sagen, ja, nein, so soll das sein und nicht.
Und wenn es halt um nicht funktionale Anforderungen geht, vor allen Dingen so Security-Aspekte, ist das halt auch eine eigene Domäne, die durchaus komplex ist, wo man halt nicht einfach einschätzen kann, will ich das jetzt so oder will ich das jetzt nicht so?
Deswegen auch so ein bisschen die Frage, wie du das siehst.
Aber ich habe letztens zum Beispiel mal testweise etwas gefragt, spaßeshalber ausprobiert für meine Anwendung, mach doch mal bitte den Pentest.
Und dann hat die halt da eine halbe Stunde rumgewirkelt und dann hat sie einen Report geliefert.
Dann habe ich gesagt, ja, ich habe den Code nicht geschrieben, sondern du.
Wenn der plausibel war.
Aber er war überraschend gut.
Also ich weiß nicht so schlimm.
Und auch der Pentest hat überraschend gut.
Würde ich 20.000 Euro an den Pentesting-Tester zahlen oder die einnehmen?
Pentester?
Habe ich die 20.000 Euro nicht, würde ich die AI fragen.
Ja.
Im Zweifel auf jeden Fall besser als gar nichts, definitiv.
Wir nähern uns auch so langsam, glaube ich, der Marke, die wir so ein bisschen anpeilen für den Podcast.
Und ich habe noch so zwei Sachen im Kopf.
Das eine ist ja unser Abschlusssegment sozusagen, aber vorher nochmal die Frage, was du unseren Zuhörern, die sagen wir mal wahrscheinlich irgendwie Entscheider in so Softwareentwicklungsorganisationen sind, empfehlen würdest.
mit den Themen auseinandersetzen, Juniors einstellen, die quasi da experimentierfreudiger und vielleicht auch offener dafür sind.
Dann schauen, dass man die Architektur auch darauf vorbereitet, dass man also einen strukturierten Plan hat, da Guardrails einzieht, dass man jemanden einstellt, der tatsächlich auch sich explizit damit beschäftigen soll.
Was kann man tun?
Was sollte man tun?
Genau.
Was gibt es weitere Dinge, die du empfehlen würdest?
Was ich vorher vielleicht nochmal...
was ich vorher sagte, eine Geschichte erzählen mit einer goldenen Zukunft, in der sich die Leute wiederfinden können.
Sehr guter Punkt.
Ja, genau.
Wunderbar.
Ja, und dann vielleicht noch zum Abschluss fragen wir immer unsere Gäste, und du bist der erste Gast, deswegen bist du die erste Person, die wir fragen, so Reality-Check, also was sind so Momente gewesen, die du in letzter Zeit wahrgenommen hast, wo du gedacht hast, so what the fuck, so wie konnte das jetzt?
oder wie konnte die KI daran scheitern?
Und andersrum, was ist für dich gerade so der heißeste Scheiß, würde ich fast sagen, der, wo du sagst, oh, da muss ich mich unbedingt mit beschäftigen und das ist super spannend.
Ja, also super spannend ist sicherlich das ganze Thema Gastown.
Also erstmal googeln, das ist, glaube ich, sehr spannend.
Und das Zweite, was, oh my God, Momente sind zwei.
Ich habe in meinen Projekten in der Regel zwei oder drei Templating-Engines, weil es so sein muss.
Und ich kriege es nicht hin, der AI klarzumachen, welche Templating-Syntax sie für welches Template nimmt.
Die sagt, oh Template, dann nehme ich doch die Syntax.
Und dann nimmt sie immer den Go-Text-Syntax-Templating statt den Chat oder sie nimmt das Chat und dann für AHA-Tempel.
Und kommt einmal durcheinander und dann habe ich schon den Cloud MD reingeschrieben und überall und irgendwie trotzdem nächstes Mal nimmt sie wieder den falschen Syntax für das falsche Template.
Also das ist sozusagen, was irgendwie gar nicht geht, wo sie nicht weiterkommt und auch nicht mit Opus 4.5.
Und das andere, ich habe letztens mal ausprobiert, die AI einen Font zu erstellen lassen.
Die AI einen Font erstellen lassen.
Ich dachte, ich könnte auch eine Font für meine Webseite machen.
Wäre doch schön.
Einen eigenen Font.
Ich habe bei so einem Geldanbieter, da habe ich so einen Font gesehen, dachte ich, ach schön, wir haben einen eigenen Font.
Und dann dachte ich, ach ja, mit der AI kriege ich ja vielleicht auch meinen eigenen Font.
Und dann habe ich halt gesagt, mach mir mal einen Font, der zu meinem Businessmodell passt.
Und dann hat die AI angefangen, mit Python-Tools und Font-Tools einen Font zu generieren und hat halt überhaupt null funktioniert.
Ja, also das hat komplett nicht funktioniert.
Und dann dachte ich, jetzt bin ich schlau und lasse erst mal einen Plan machen.
Dann habe ich gesagt, mach mal erst mal für jedes Zeichen einen Plan, wie das aussieht.
Und dann habe ich da drei Stunden reingesteckt nochmal und dann war das Ergebnis das Gleiche.
Und dann sagt sie, jetzt bin ich fertig, jetzt alles super.
Und dann hat halt das J irgendwie einen Knick drin oder beim O fehlt das Loch in der Mitte oder solche Sachen.
Also da selbst mit, guck mal hier.
ist Image Magic, da kannst du den Font rendern, dann kannst du es angucken und dann vergleich doch bitte die Glyphen mit dem, was du machen wolltest und so weiter.
Macht sie alles, sagt, jetzt bin ich fertig und dann hat das Ohr halt immer noch kein Loch.
Also das ging komplett nach hinten los.
Ja, Alphilium.
Ich habe immer wieder so ähnliche Situationen.
Auch bei, gerade jetzt, wo du Image gesagt hast, Google Gemini, ich generiere Das geilste Hintergrund-Image überhaupt.
Sieht richtig cool aus.
Will eine kleine Änderung machen.
Komplett missverstanden.
Oder ich wollte es spiegeln.
Einfach nur, dass es umgedreht ist.
Ging nicht.
Hat immer wieder das Gleiche präsentiert und gesagt, ja, jetzt habe ich es gespiegelt.
Bin happy.
Das erinnert mich ein bisschen, als wenn du ein Inhaltsverzeichnis in Word hinzufügst oder halt irgendwie ein Bild in einem Word-Dokument leicht verschiebst und zack, ist alles anders.
Ja, einige Sachen ändern sich nie.
So sieht es aus.
Ja, vielen Dank, Stefan.
Das war sehr, sehr spannend und genauso cool, wie ich mir das vorgestellt habe.
Vielleicht noch cooler.
Ich hoffe, es hat dir auch gefallen.
Hast du noch irgendwelche letzten Worte, die du unseren Hörern mit auf den Weg geben möchtest?
Ich fand es super.
und mehr AI.
Und alle, die einen kostenlosen Vortrag von dir in der Firma haben wollen, melden sich und wir leiten es weiter.
Alles klar.
Vielen Dank.