Wie KI die Entwicklung von Unternehmenssoftware verändert

[0:02] – John Burke: [Musik] Hallo, ich bin John Burke, CTO von Nemertes, und hier bei mir ist mein Co-Moderator…

[0:07] – Scott Robohn: Ich bin Scott Robohn, CEO von Solutional und Moderator von „Total Network Operations“, einer Schwester-Sendung hier bei Packet Pushers.

[0:14] – John Burke: Und Sie hören „Heavy Strategy“, die Sendung, die versucht, die richtigen Fragen zu stellen, statt die richtigen Antworten zu geben. Zu Gast ist heute Andrew Wertkin, Chief Strategy Officer bei BlueCat Networks. Andrew, vielen Dank, dass Sie bei uns sind.

[0:25] – Andrew Wertkin: Vielen Dank für die Einladung. Ich freue mich darauf.

[0:30] – John Burke: Und in der heutigen Sendung werden wir genau das besprechen, worüber ein Netzwerkmanagement-Unternehmen sprechen würde: die Herausforderungen beim Einsatz von KI für die Automatisierung von Unternehmensnetzwerken. Denn wir alle wissen, dass IT-Fachleute KI dazu nutzen, die Automatisierung von Netzwerken zu beschleunigen. Warum ist das nicht so einfach, wie es klingt? Warum können wir uns nicht in 99 % der Fälle einfach auf Claudes Wort verlassen?

[0:50] – Scott Robohn: Ja, weißt du, schalte es einfach in den „Permissive“-Modus und klick auf „Go“. [Gelächter] Fertig.

[0:55] – Andrew Wertkin: Ja. Weißt du, es ist interessant, denn ich entwickle Software, seit ich denken kann. Es gibt einen Grund, warum ich nicht schreiben kann: Ich habe mein ganzes Leben lang getippt. Und dieses Handwerk hat mir sehr, sehr viel Spaß gemacht. Aber auf der Netzwerkseite war es interessant, denn die Teams haben wirklich gute Arbeit geleistet. Und mit „den Teams“ meine ich einfach die Netzwerkingenieure da draußen, die Automatisierung, Pre-Code-Generierung und Pre-LLM vorantreiben und wirklich versuchen, die Methodik der Softwareentwicklung weiterzuentwickeln – ähnlich wie Softwareentwicklungsunternehmen Software entwickeln.

[1:37] – Andrew Wertkin: Und bei KI und bei durch LLM generiertem Code ist es ohne diese Best Practices schon beängstigend, sich vorzustellen, was im Netzwerk alles passieren könnte. Es läuft also wahrscheinlich auf eine weitere Transformation in diesen Teams hin zu ausgefeilteren Prozessen rund um die Softwareentwicklung hinaus, denn je schneller Dinge erstellt werden können, desto mehr kann wahrscheinlich auch schiefgehen.

[2:04] – Scott Robohn: Du vertrittst eine These, die mich wirklich anspricht, oder? Ich würde sagen, eine meiner weiteren Rollen ist die des Mitbegründers einer Organisation namens „Network Automation Forum“. Und zum Zeitpunkt dieser Aufnahme komme ich gerade von unserem letzten Treffen, der AutoCon 5 in München, zurück. Wir haben diese Diskussion über die Vorbehalte gegenüber der Einführung von Netzwerkautomatisierung bereits begonnen, bevor KI ins Spiel kam, nicht wahr? Es gab schon immer einen gewissen Widerstand dagegen, die Automatisierung auf Hochtouren laufen zu lassen, und jetzt, wo die Bots und Agenten ins Spiel kommen, wird mit den Augen gerollt und die Skepsis ist groß.

[2:55] – Scott Robohn: Das würde ich gerne als Teil unseres Gesprächs hier aufgreifen, um zu sagen: Ich stimme dir zu. Wir müssen dafür sorgen, dass sich hervorragende Best Practices in der Software-Engineering und Softwareentwicklung etablieren, denn vieles, was wir im Netzwerkbetrieb tun, ist davon abhängig. Ich weiß, dass ich mir hier am Anfang vielleicht etwas zu viel Zeit nehme, aber das ist meine Sichtweise, und ich freue mich wirklich sehr auf diesen Dialog mit dir.

[3:20] – John Burke: Ja, super, und ich finde, du liegst goldrichtig. Das Misstrauen gegenüber Automatisierung in der Netzwerkbranche reicht 25 Jahre zurück. Wir haben schon oft schwer darunter gelitten, dass wir der Automatisierung zu weit und zu schnell vertraut haben.

[3:41] – Andrew Wertkin: Ja. Was ich immer wieder höre, ist Vertrauen, vor allem bei wiederholbaren, vorlagenbasierten Aktionen.

[3:46] – John Burke: Ja.

[3:46] – Andrew Wertkin: Wenn es über das Einfache, Wiederholbare und Vorlagenbasierte hinausgeht, dann kommt es ziemlich stark zu einem Vertrauensverlust. Und wie wir von unseren Kollegen wissen, ist ein Anbieter, der vorbeikommt und sagt: „Einfach zeigen und klicken, einfache, unkomplizierte Automatisierung“, wahrscheinlich der schlechteste Weg, um das Vertrauen des Endkunden zu gewinnen. Je undurchsichtiger es ist, desto größer ist in der Regel die Besorgnis, was dieses potenzielle Misstrauen in der Welt der KI noch verstärkt. Ich weiß es nicht. Wir können darüber sprechen, wie man das angehen und mehr Vertrauen schaffen kann, aber das gilt nicht nur für den Netzwerkbereich. Es betrifft offensichtlich alle Bereiche.

[4:44] – Andrew Wertkin: Viele von uns haben in Umgebungen gearbeitet, in denen keine Quellcodeverwaltung genutzt wurde, in denen Reviews nicht ordnungsgemäß durchgeführt wurden, in denen Code von anderswo kopiert und eingefügt wurde, ohne auf die aktuelle Umgebung hin überprüft zu werden, und so könnte man endlos weitermachen. Und man kann innerhalb eines Tages auf zehn dieser schwerwiegenden Probleme stoßen, wenn man den Prozess nur beschleunigt hat.

[5:11] – Andrew Wertkin: Das birgt zwar ein enormes Potenzial, aber es geht nicht nur um Softwareentwicklung, oder? Es geht um das Debuggen, darum, herauszufinden, was in Live-Umgebungen vor sich geht und warum es nicht funktioniert. In einigen dieser Bereiche ist es einfach unglaublich, wie viel Arbeit in kurzer Zeit erledigt werden kann – vorausgesetzt, man hat jemanden mit dem richtigen Fachwissen und bleibt kritisch gegenüber dem, was einem gesagt wird. Einfach absolut erstaunlich. Solange man nicht einfach sagt: „Oh, du hast gesagt, es ist das, also ist es das. Okay, dann sollte ich das tun. Dann sollte ich das tun.“ Genau da liegt das Problem, denn wir wissen, dass LLMs – egal, wie sehr man sie auch anders zu lenken versucht – dazu neigen, ziemlich schwarz-weiß zu denken und zu glauben, sie hätten die Ursache gefunden.

[5:58] – John Burke: Was mir an der Idee der Beschleunigung der Automatisierung gefällt, ist der Gedanke, dass man den Leuten dabei helfen kann, bessere Vorgehensweisen schneller umzusetzen. Wenn sie bei der KI bessere Vorgehensweisen anwenden, werden sie ihre Automatisierungsprojekte häufiger zu Ende bringen. Sie werden sie nicht halb oder zu drei Vierteln fertig lassen, ohne sie jemals vollständig zu debuggen oder zu dokumentieren, oder? Und dann zum nächsten Notfall übergehen. Die Wahrscheinlichkeit ist größer, dass sie innerhalb eines einzigen Tages, zweier Tage, einer Woche oder zweier Wochen das Projekt vollständig abschließen und etwas hinterlassen, das sie tatsächlich wieder mit Zuversicht nutzen können – und nicht mit Angst und Zittern.

[6:39] – Andrew Wertkin: Ja. Ja. Vieles davon hat einfach mit der Architektur zu tun. Vieles davon dreht sich um – nun ja – zum einen um die richtige Einstellung als Entwickler, die lautet: Ich schreibe das für die Leute, die es in Zukunft warten werden, also werde ich das im Hinterkopf behalten.

[6:58] – John Burke: Das geht doch ganz von selbst, oder? Jeder Entwickler denkt vom ersten Tag an darüber nach.

[6:58] – Andrew Wertkin: Ja. Genau. [Gelächter] Ja, vor allem, wenn es damit anfing: „Oh, wir brauchen ein schnelles Skript, um dieses Problem zu lösen“, und dann findet es jemand sechs Monate später.

[7:15] – Andrew Wertkin: Vieles hängt also von der Architektur ab. Ein Großteil dessen, was in dieser Automatisierung enthalten sein wird, wird sich wiederholen, oder? Wie authentifizieren wir uns? Welche Standards gelten für die Protokollierung, oder wie wollen wir protokollieren? Wie stellen wir die Schnittstelle zu unseren Geräten her? Wie werden Passwörter gespeichert, und wie holen wir sie aus den Speichern heraus? Wie wollen wir testen, oder wie sollten wir über das Rückgängigmachen von Änderungen nachdenken, oder was auch immer der Fall sein mag? Fast alles, was ich gerade aufgezählt habe, lässt sich mit dieser geeigneten Methodik wiederholen. Dann muss man nur noch die eigene Geschäftslogik hinzufügen – nicht unbedingt all diese anderen Teile –, und so bleibt der gesamte Code auf dem neuesten Stand, wird getestet und so weiter.

[8:01] – Andrew Wertkin: Aber es ist wirklich einfach, schnell etwas zu entwickeln. Und alles, was ich gerade aufgezählt habe, klingt auch so, als würde es länger dauern, als wenn einfach acht Leute acht verschiedene, voll funktionsfähige Skripte oder Anwendungen von A bis Z aus dem Ärmel schütteln würden – was auch immer wir gerade entwickeln. Daher ist es wahrscheinlich wichtiger denn je, von Anfang an den richtigen Weg einzuschlagen und darüber nachzudenken, wie wir das Ganze nachhaltig gestalten können, wo Menschen in den Prozess eingebunden werden und wo es entscheidend ist, dass sie eingebunden sind, und welche Vorgehensweisen wir anwenden werden, um dies sicher zu bewerkstelligen.

[8:50] – Andrew Wertkin: Vieles davon sind dieselben Dinge, über die wir schon immer nachgedacht haben oder die uns beim Entwickeln von Software in den letzten Jahrzehnten beschäftigt haben, oder? Ein Teil davon liegt einfach daran, wie schnell das heute möglich ist. Und es geht nicht nur darum, dass Leute Sachen von Stack Exchange kopieren und einfügen; jeder kann sich Code generieren lassen, der in dieser Umgebung funktioniert. Das ist ganz einfach, und das war vor zwei Jahren noch nicht der Fall.

[9:28] – Scott Robohn: Nun, ich denke, wir befinden uns mitten in dieser sich schnell verändernden und experimentellen Zeit, oder? Wenn man nur ein paar Jahre zurückblickt, haben die Leute ihre ersten Erfahrungen mit chatbasierten Tools gemacht und dabei sehr unterschiedliche Ergebnisse erzielt. Diese ganze Sache mit dem Nichtdeterminismus von LLMs – das war unsere erste Erfahrung. Und dann erlebten wir das Aufkommen des „Vibe-Codings“ und sahen, welch großartiger Wegbereiter es für das Prototyping ist, aber auch, was für ein Spaghetti-Chaos es in einer Unternehmens-Codebasis anrichten kann, und jetzt tauchen neue Methodiken wie die spezifikationsgesteuerte Entwicklung und die testgetriebene Entwicklung auf. Ich glaube, wir erleben gerade, wie sich die Erkenntnis durchsetzt: „Okay, so setze ich die Tools ein, und so kann ich tatsächlich Vertrauen in die Technologien aufbauen“ – im Gegensatz zu meiner ersten Erfahrung mit ChatGPT 3.x, oder? Was beobachtest du in dieser Hinsicht, angesichts des Aufkommens dieser Strategien und wiederverwendbaren Tools, die gerade entstehen?

[10:30] – Andrew Wertkin: Ja. Nein, wir sehen sie auf jeden Fall, und wir haben mit einigen davon experimentiert und sie übernommen. Ich glaube, wo wir – mein Unternehmen und auch ich persönlich – den größten Erfolg hatten, ist interessanterweise der Bereich, für den ich in meiner Karriere wahrscheinlich am wenigsten Zeit aufgewendet habe (nicht das Unternehmen, sondern ich persönlich), nämlich die Entwicklung der Spezifikationen im Vorfeld und die Zusammenarbeit mit dem LLM bei Kompromissentscheidungen. Hier kann ich meine Erfahrung einbringen: Wie sollten wir das angehen? Diese Zeit im Vorfeld zu investieren, das Ganze in überschaubare Abschnitte zu unterteilen und dann die entsprechenden Leitplanken zu setzen – solche Dinge haben einen entscheidenden Unterschied gemacht, im Gegensatz zum Versuch, eine Eingabe zu verfassen, die genau beschreibt, was man will.

[11:27] – Andrew Wertkin: Es ist diese Art der iterativen Spezifikations- und Testentwicklung, die wirklich damit beginnt: „Okay, ich möchte einen schnellen eBPF-Logger erstellen“, richtig? Das habe ich noch nie gemacht, oder? Und daher weiß ich noch nicht einmal, wo die Kompromisse liegen – wie sehr kann ich also dem vertrauen, was dabei herauskommt? Aber ich kann auf einer sehr hohen Ebene beginnen: Ich möchte das tun. Was ist deine Absicht?

[11:57] – John Burke: Genau. Ja. Ich denke, es gibt da noch einen wirklich wichtigen Punkt, der sozusagen eine Ebene darunter liegt, nämlich dass es entscheidend ist, seine Absichten und Anforderungen sehr klar zu formulieren. Wenn Software die Einstellungen an der Hardware in Ihrem Netzwerk verändert, führt das Herumspielen mit den falschen Einstellungen dazu, dass der Datenverkehr unterbrochen wird oder der Prozessor so stark überlastet wird, dass es zu massiven Leistungseinbußen kommt, da er möglicherweise seine gesamte Zeit damit verbringt, Protokolle zu erstellen und zu versenden. Man befindet sich also in einem Umfeld, in dem Fehler in der Infrastruktur auftreten können – und zwar mit der Geschwindigkeit der Automatisierung –, die wirklich enorme Folgen haben können.

[12:47] – Andrew Wertkin: Ja. Genau. Ich meine, in unserer DNS-Welt, allein auf der öffentlichen Seite: Wenn man sich die letzten großen Ausfälle ansieht, die von riesigen börsennotierten Unternehmen gemeldet wurden, dann waren meiner Meinung nach 80 % davon automatisierungsgesteuerte Änderungen am DNS, die das gesamte System lahmgelegt haben. Und ich werde dafür keineswegs einem LLM die Schuld geben. Aber je schneller man Lösungen finden kann und je sicherer insbesondere der Programmierpartner, der Debugging-Partner oder der Performance-Partner ist – ganz gleich, um welchen Anwendungsfall es sich handelt –, desto eher neigt man dazu zu sagen: „Ja, okay.“ Und dann leiden alle unter „Permission Fatigue“, und die Finger tippen versehentlich weiter, und man drückt einfach immer wieder drauf. Es kommt also auch darauf an, wie wir das Verhalten angemessen überwachen und sicherstellen, dass solche Dinge nicht passieren.

[13:46] – Andrew Wertkin: Aber ja, eine erfolgreichere Formulierung der Absicht umfasst genau diese Dinge. Was könnte deiner Meinung nach möglicherweise schiefgehen? Was bereitet dir Sorgen? Was stellst du sicher, dass tatsächlich getestet wird? Was bedeutet „Last“ hier eigentlich? Wie sollte es sich unter Last verhalten? Man braucht all das nicht von vornherein, aber es ist gut, über die richtige Erfahrung zu verfügen, um die Kategorien von Dingen zu kennen, die man wahrscheinlich berücksichtigen sollte.

[14:21] – Andrew Wertkin: Was du aber nicht tun musst – und ich denke, das hat sich in den letzten sechs Monaten, einer wahnsinnig kurzen Zeitspanne, sowohl bei den Tools als auch bei den Prozessen wirklich weiterentwickelt –, ist, zunächst eine vierseitige Anleitung darüber zu schreiben, was genau zu liefern ist. Das tust du, wenn du ein kostengünstigeres, eher auf Laufraten ausgerichtetes Modell anstelle eines „Frontier“-Modells verwendest – aber dann lass einfach ein „Frontier“-Modell die Spezifikation für das Laufraten-Modell schreiben. Du wirst bei der Erstellung von Prompts niemals so gut sein wie ein LLM, oder?

[14:57] – Scott Robohn: Nun, ich habe eine Technik eingebaut, bei der ich das LLM im Grunde bitte, mich zu befragen. Ich bringe eineinhalb Seiten mit einer recht detaillierten Absichtsspezifikation mit, und wenn man diesen Prozess nutzt, um alle erforderlichen Markdown-Dateien für SDD zu erstellen, ist das erstens kostengünstig. Ich weiß, dass hier Token-Kosten anfallen, aber ich erstelle menschenlesbare Dokumente, die ich nach Abschluss eines Interviewprozesses validieren und überprüfen kann. Und letzte Woche habe ich einen tollen Kommentar gehört: Der Code ist in gewisser Weise kostenlos. Wir sind es gewohnt, uns vorzustellen, wie wir uns abmühen, den Code genau richtig hinzubekommen, aber jetzt bitten wir Agenten, den Code zu schreiben, und wir können iterieren und Dinge verwerfen, die wie Müll aussehen. Und man muss immer noch über genügend Fachwissen verfügen, um zu erkennen, dass es sich tatsächlich um Müll handelt, oder?

[15:52] – Andrew Wertkin: Genau. Und dieser letzte Punkt ist, auf der persönlichen Ebene, gewissermaßen meine Befürchtung, wie alles in 10 Jahren aussehen wird, aber es ist auch das Entscheidendste im Moment. Ohne das Fachwissen und die Erfahrung sowie das Know-how darüber, wie Dinge scheitern können, wie sie funktionieren sollten, wie sie auf elegante Weise ausfallen sollten und so weiter, handelt man sich Ärger ein. Aber ja, das gefällt mir, und ich mache das auch, wahrscheinlich auf eine weniger straffe Art und Weise als du, aber diese Art von: „Woran denke ich hier gerade nicht?“

[16:29] – John Burke: Genau. Was könnte hier sonst noch schiefgehen? Und wenn die LLMs dir genauso gerne den tödlich giftigen Pilz bringen wie den leckeren, essbaren Pilz und sie [räuspert sich] bei flüchtiger Betrachtung gleich aussehen, dann wird diese Art von Fachwissen unersetzbar und absolut notwendig.

[16:50] – Andrew Wertkin: Ja. Und Folgendes passiert dann, und deshalb ist der Prozess hier so wichtig: Die Leute setzen sich zusammen und glauben, sie seien mit dem LLM auf einer Wellenlänge, und über ein paar Wochen hinweg scheint das auch zu stimmen. Es scheint sich an Dinge zu erinnern. Und dann, am siebten Tag, beginnt man eine neue Sitzung, und es scheint alles vergessen zu haben, was es jemals wusste, und es hat sich im Laufe der Woche gewissermaßen verschlechtert, weil man das nicht dokumentiert hat. Man hat die entsprechenden Erinnerungen nicht gespeichert und nicht dafür gesorgt, dass man die Prompts und alles andere aktualisiert. Und dann trifft es eine Entscheidung, die unglaublich naiv ist, und weil wir diese Dinge vermenschlichen, kommt einem der Gedanke: „Arbeite ich mit einem Doppelgänger zusammen? Wer ist diese Person, mit der ich arbeite? Wie ist es möglich, dass es das vergessen hat?“

[17:34] – Andrew Wertkin: Es treten also viele Fehler in jenen Momenten auf, in denen der Bediener, Entwickler, Netzwerkbetreiber – wer auch immer es nutzt – sich über den Zustand des Sitzungsspeichers im Unklaren ist und davon ausgeht, dass etwas passieren wird, das zwar nicht unbedingt deterministisch ist, aber zumindest auf unseren bisherigen Erfahrungen basiert. Und dann kommt die Überraschung. Und wie nennen wir das? Zum Teil ist es einfach eine „Wiederentdeckungssteuer“. Ich werde viel Geld – in Form von Tokens, Credits oder was auch immer – dafür ausgeben, immer und immer wieder dasselbe neu zu entdecken, weil es nicht angemessen dokumentiert ist.

[18:22] – Andrew Wertkin: Und das sind Dinge, in denen die LLMs im Allgemeinen – je nach Programmierwerkzeug – wirklich gut sind. Ich nutze meistens Claude, aber unabhängig davon habe ich schon mehrere ausprobiert. Jedes Mal, wenn ich eine Sitzung beende, frage ich: Was haben wir gemacht? Was musstet ihr neu entdecken? Und was von dem, was ihr neu entdecken musstet, sollten wir angemessen dokumentieren, damit ihr es nicht noch einmal neu entdecken müsst? Und das ist noch nicht alles, denn Experimentieren funktioniert. Manchmal lernt man eine Menge, wenn man Fehler macht.

[18:54] – Andrew Wertkin: Und vielleicht noch einmal zurück zur persönlichen, aber dennoch professionellen Seite von „härtbarer“ Software: Software, die, wie wir sagen, „unter Druck“ funktioniert. Sie funktioniert nicht nur im Labor, sie funktioniert nicht nur in den Idealfällen. Sie funktioniert. Setzt man sie unter Druck, funktioniert sie trotzdem. Um diesen Punkt zu erreichen, braucht man Erfahrung aus der Praxis – aber insbesondere aus Fehlschlägen.

[19:21] – Andrew Wertkin: Es ist, als ob etwas faul ist, weil man diesen Fehler schon einmal gemacht hat oder dabei war, als es passiert ist. Und diese Art des Lernens ist ganz spezifisch für die sehr großen Kontextumfänge unseres Gehirns. Man muss nicht einmal seine Notizen durchsehen. Man erkennt dieses Muster sofort, wenn man schon einmal gescheitert ist. Es ist einfach fest verdrahtet. Und ich weiß einfach nicht, wie solche Dinge ohne einen Sinn geschehen sollen. Ohne einen Sinn.

[20:08] – John Burke: Und ich höre manchmal Leute sagen, dass es nicht mehr lange dauern wird, bis wir diese Skripte oder Programme gar nicht mehr von uns selbst entwickeln lassen, sondern von einer KI. Wir werden ihr einfach sagen, was passieren soll. Sie wird im Hintergrund ein Programm starten, es losschicken und die Aufgabe erledigen. Und wenn wir das nächste Mal etwas erledigt haben wollen, wird sie ein Programm generieren und es zur Ausführung losschicken, und schon sind wir fertig. Sie wird also nicht einfach nur Automatisierung für uns schaffen; sie wird die Automatisierung sein.

[20:34] – Andrew Wertkin: Sure.

[20:34] – John Burke: Und für mich ist das, was du gerade sagst, die Gegenreaktion darauf. Es ist so: Okay, aber wenn es dieses Problem zum zweiten Mal sieht und es an der Zeit ist, ein Programm zu generieren, um es zu lösen – wird es sich daran erinnern, wie es das Problem beim letzten Mal gelöst hat? Wird es sich daran erinnern, was schiefgelaufen ist und wie es behoben wurde? Vielleicht, vielleicht auch nicht. Ich denke, solange dieses Problem nicht gelöst ist – und zwar durch Lösungen, die auch unter Stress funktionieren, wie du sagst, sodass die KI mir, egal wie wütend ich bin, wenn ich die Eingabe an sie sende, immer noch die richtige und gute Antwort gibt –, ist es noch nicht gelöst.

[21:08] – Andrew Wertkin: Ja, dann ist das Problem noch nicht gelöst. Und das Einzige, was ich dem noch hinzufügen wollte, ist, dass man auf das gegenteilige Problem stößt, denn die LLMs suchen im Grunde nach Mustern. Wenn also etwas so aussieht, als würde es zu diesem Muster passen, heißt das noch lange nicht, dass es die richtige Antwort ist. Und ironischerweise ist es so: Wenn man nur ein paar Fälle dieser Art hat – zum Beispiel: „Etwas ist fehlgeschlagen, hier ist der Grund dafür, ich kenne das Muster“ –, dann ist es wahrscheinlicher, dass etwas gewaltsam in dieses Muster gepresst wird. Sie werden den runden Pflock in das quadratische Loch hämmern, wenn er fast passt.

[21:52] – Andrew Wertkin: Und ich glaube, es gibt immer noch eine gewisse Kluft, besonders in der Welt der Brownfield-Projekte, zwischen „Okay, ich werde einfach meine Absicht formulieren, und die Skripte werden geschrieben, die Arbeit wird erledigt, und ich muss mir das nie wieder ansehen“ und der tatsächlichen Umsetzung in einem Unternehmensnetzwerk, wo man heute noch nicht über alle Tools verfügt, um das zu bewerkstelligen. Man hat heute nicht unbedingt das Budget, um das zu realisieren. Und man hat eine Vorgeschichte, und diese Vorgeschichte beinhaltet Dinge, die in der Welt der KI nicht gut sind, nämlich Dinge wie „Stammeswissen“ und Sonderlösungen. Und, wissen Sie, das wurde aus einem ganz bestimmten Grund so gemacht, aber es ist mit gelbem Absperrband umzäunt. Niemand weiß warum, aber wir wissen einfach, dass alles zusammenbricht, wenn wir es ändern, also ändern wir es nicht mehr. Das wurde nie dokumentiert. Das wurde nicht dokumentiert.

[22:43] – Andrew Wertkin: Ich komme also einfach auf eines der wirklich bekannten Grundlagwerke der Softwareentwicklung zurück. Die Werkzeuge und Taktiken haben sich geändert, aber dieses Buch ist so aktuell wie eh und je: Martin Fowlers „Refactoring“. Ich glaube, im Vorwort, in den ersten paar Absätzen, heißt es: Wenn ihr nicht testen könnt, stellt dieses Buch zurück ins Regal. Ich paraphrasiere, aber es ist in etwa so gemeint: Man kann etwas nicht ändern, wenn man es nicht testen kann. Und wie soll man das in dieser Welt des „Stammeswissens“ und der Sonderfälle angehen, in der nicht alles einem Muster folgt? Vor allem, wenn es nichts gibt, woran man testen könnte. In Ihrem Labor gibt es diese Sonderfälle nicht. In Ihrem Labor stellt sich die Frage: Wie testen wir das eigentlich angemessen?

[23:39] – Andrew Wertkin: Und genau das ist der Grund für diesen langwierigen Change-Management-Prozess. Die Organisation hat gelernt: Wenn wir daran rütteln, geht etwas kaputt. Deshalb wird das nur in einem solchen Änderungsfenster passieren, in dem wir dreieinhalb Stunden Zeit haben und während dieses Zeitfensters nichts anderes eingeplant werden darf. Das zugrunde liegende Problem wurde nie behoben; man hat einfach einen Prozess darum herum aufgebaut. Und deshalb müssen sich auch Unternehmen und Konzerne überlegen, wo sie bei diesen Dingen ansetzen sollen. Und um das Offensichtliche zu betonen: Neue Systeme werden von vornherein so aufgebaut. Großartig. Etwas Bestehendes zu ändern – sei es Software oder Netzwerkarchitektur – ist für Menschen und LLMs weitaus schwieriger. Aber zumindest verfügen die Menschen hoffentlich über ein gewisses Maß an „Stammeswissen“.

[24:33] – Scott Robohn: Eine weitere spannende Sache, die meiner Meinung nach vor uns liegt – in Anlehnung an das, was du gerade dargelegt hast: Wenn ich ein LLM habe, sieht alles wie eine Eingabeanweisung aus, oder? Und ich glaube, viele von uns erkennen gerade, dass nicht alles ein Problem für ein LLM ist. Wir haben diese wirklich interessante und potenziell nützliche Reihe neuer Berechnungstechniken vor uns, und wir haben die anderen noch nicht alle abgeschafft. Maschinelles Lernen ist für andere Dinge im KI-Bereich immer noch sehr nützlich. Statistische Regression kostet mich, soweit ich weiß, keine Tokens, oder?

[25:11] – John Burke: Richtig.

[25:11] – Scott Robohn: Ich erweitere also meinen Werkzeugkasten. Und die wirklich spannende Herausforderung, die vor uns allen liegt, besteht darin, hier die richtigen Werkzeuge für die jeweilige Aufgabe einzusetzen: LLMs, wo sie Sinn machen, ML, wo es Sinn macht, Regression, wo es Sinn macht. Vielleicht könnte für das von dir angesprochene Problem – dass jedes Mal, wenn die Frage gestellt wird, das Rad neu erfunden wird – ein Teil meiner Vorgaben lauten: Okay, ich habe ein Problem gelöst und es in meinen IT-Servicekatalog aufgenommen. Und wenn es in meinem Servicekatalog etwas gibt, das zu 90 % oder besser zu dieser Eingabe passt, dann nutze das, was im Servicekatalog steht, und verschwende keine Tokens darauf, eine weitere Lösung dafür zu entwickeln. Richtig? Und ich spiele hier nur ein bisschen mit dem Gedanken, oder? Aber ich denke, das sind alles Ansätze, die wir auf den Tisch legen müssen, während wir gemeinsam versuchen, diese Dinge zu klären. Und ich sehe das viel positiver, als dass ich zynisch darüber wäre. Frag mich in einem Jahr noch einmal, ob ich immer noch so denke.

[26:05] – Andrew Wertkin: Also nein, was den Servicekatalog angeht, ist das interessant. Ich meine, die gute Nachricht ist, dass man einfach das LLM überprüfen lassen kann, ob man dieses Problem schon einmal gelöst hat, und noch einmal: Die sind super gut darin, Muster abzugleichen. Sie werden etwas finden. Und tatsächlich ist von all den Techniken, die ich im letzten Jahr entwickelt habe, diese enge Verbindung zwischen der Dokumentation dessen, was ich getan habe, und dem, was ich tatsächlich getan habe, [schnaubt] super wertvoll, sowohl aus der Perspektive von…

[26:43] – Andrew Wertkin: Eine kurze Geschichte. Vor vielen Jahren war ich CTO eines Unternehmens im Bereich Application Lifecycle Management. Wir haben also Software entwickelt, die beim Erstellen von Software hilft, und ein Teil unseres idealen Kundenprofils betraf sicherheitsrelevante Embedded-Software, bei der ein Fehler dem Bediener Schaden zufügen könnte, zum Beispiel in der Automobilindustrie oder wo auch immer.

[27:08] – Andrew Wertkin: Und in dieser Welt gibt es alle möglichen Standards, wie ISO 26262 und Automotive SPICE, und so weiter und so fort. Und Teil dieser Standards ist, dass eine Rückverfolgbarkeit zwischen Anforderungen und Code bestehen muss, richtig? Und wenn sich die Anforderungen oder der Code ändern, wird diese Rückverfolgbarkeit potenziell problematisch, und ich muss mich dann darum kümmern und nach all diesen Auswirkungen suchen. Ich muss übrigens bei dieser Änderung angeben: Ich habe den Code geändert, aber die Anforderung ist weiterhin korrekt, der Testfall ist weiterhin korrekt und die Architektur ist weiterhin korrekt. Das muss ich für alle diese verdächtigen Verknüpfungen tun.

[27:38] – Andrew Wertkin: Und man wird niemanden, der B2B-Software entwickelt, davon überzeugen können, dass er dieses Maß an Rückverfolgbarkeit braucht, aber ich mache das, wenn ich LLM-basierte Entwicklung betreibe, weil es einfach großartig ist. Zum einen macht es mir einfach Spaß, zum anderen aber auch, weil das LLM dann die Rückverfolgung übernimmt und schnell herausfinden kann, warum wir etwas so gemacht haben, wie wir es gemacht haben – denn es kann bis zur Dokumentation zurückverfolgen. Und das LLM schreibt diese Dokumentation selbst und weiß, wie es die Dokumentation für sich selbst verfassen muss.

[28:14] – Andrew Wertkin: Das ist etwas, das, selbst wenn … Manchmal sage ich: „Schreib das für einen Menschen.“ Manchmal sage ich: „Schreib dieses Dokument für einen Kunden, der vielleicht weiß, wie Softwareentwicklung funktioniert, vielleicht aber auch nicht, oder der vielleicht noch nie Python installiert hat – was auch immer der Fall sein mag.“ Aber oft sage ich bei diesen Dokumenten entweder: Fügt einen Anhang speziell für ein LLM hinzu, oder schreibt das einfach für ein LLM. Erstens ist es prägnanter, und zweitens sind LLMs ziemlich gut darin, Dokumente so zu verfassen, dass sie für sie lesbar sind – sowohl aus Sicht der Effizienz als auch der Kosten beim Lesen, oder? Die von Menschen verfasste Version ist teurer.

[28:57] – Andrew Wertkin: Aber unabhängig davon geht es auch um Folgendes: Okay, nun schreibe ich nicht nur Software, die der Nächste warten kann, sondern auch Software, die das nächste LLM warten kann, und gebe ihm natürlich die Fähigkeit, schnell große Textmengen einzulesen und zu analysieren. Ja, ich hatte noch nie eine bessere Dokumentation in meinem Code oder außerhalb meines Codes. Als Mensch hätte ich niemals so viel Dokumentation erstellt – niemals –, mit der Annahme, die die meisten Menschen beim Schreiben haben: „Ja, daran werde ich mich erinnern. Ja, das ist ziemlich leicht zu lesen. Ich lese einfach den Code, das ist doch offensichtlich“ oder „Jeder würde verstehen, was ich damit gemeint habe.“

[29:46] – John Burke: Ja, genau.

[29:46] – Andrew Wertkin: Ja, ich sagte „Sortieren“. „Ich sortiere hier gerade“, weißt du. Und solche Dinge führen zu einer enormen Anzahl von Fehlern, aber das Gleiche gilt auch für etwas, das manchmal sogar noch schlimmer ist … Wie lautet das alte Sprichwort? Das Einzige, was schlimmer ist als keine Internetverbindung, ist eine miese Internetverbindung.

[30:05] – John Burke: Das stimmt. Ja.

[30:05] – Andrew Wertkin: Ja. Genauso verhält es sich mit der Dokumentation.

[30:05] – John Burke: In gewisser Weise mentorieren Sie Ihre KI sowohl dabei, ihre Fachkompetenz zu verbessern – indem Sie ihr mehr darüber beibringen, was es bedeutet, ein physisches Netzwerk aus physischen Geräten zu betreiben, welche Risiken bestehen, wo die Grenzen des Experimentierens liegen und so weiter –, als auch dabei, ein gutes Teammitglied zu sein, indem sie beispielsweise ihren Code dokumentiert und ihre Vorgehensweise erklärt.

[30:42] – Andrew Wertkin: Auf jeden Fall. Nein, das ist eine gute Analogie, denn genau das rate ich den Leuten normalerweise, besonders wenn sie bereits erfahren sind: Stell dir einfach vor, du hast vier junge bis mittel erfahrene Softwareentwickler in deinem Team, die ziemlich selbstbewusst sind und davon überzeugt sind, dass sie Recht haben. Wenn also einer von ihnen zu dir sagen würde: „Das ist nun mal der beste Weg, es zu machen“, würdest du fragen: „Warum? Welche Belege hast du dafür? Haben wir genügend Belege? Welche Alternativen hast du geprüft, bevor du zu dieser Lösung gekommen bist?“ Wenn du deine Interaktionen so betrachtest, wirst du immer die richtigen Fragen stellen.

[31:32] – Andrew Wertkin: Was die Fähigkeit angeht, schnell funktionierenden Code zu generieren, handelt es sich hier nicht um einen Junior- oder fortgeschrittenen Softwareentwickler. Aber was den Denkprozess angeht, hat ein fortgeschrittener Softwareentwickler in vielen Fällen einen besseren Denkprozess. Mit anderen Worten: Es geht um den Denkprozess. Es geht nicht um Mustererkennung und die anderen „Zaubertricks“ von LLMs.

[32:00] – Andrew Wertkin: Ich glaube, das ist der größte Fehler. Ob es nun Vorurteile, Bestätigungsfehler oder etwas anderes sind – die Leute suchen nach dieser Art von positiver Bestätigung: „So werden wir es machen.“ Und wenn sie sagen: „Hey, ich habe darüber nachgedacht. Ist das eine gute Idee?“, dann wissen wir alle, dass das die schlechteste Art ist, mit einem LLM zu interagieren, denn es wird dir freudig antworten: „Brillant. Wow. Ja, du bist so schlau. Das ist der beste Ansatz, den ich je gehört habe.“

[32:33] – Scott Robohn: Füge einfach „keine Schmeichelei“ in jede deiner Anweisungen ein.

[32:38] – Andrew Wertkin: [lacht] Ja. Nein, zu 100 %, mach das, denn ich brauche das nicht von meinen Kollegen, meinen Mitarbeitern und meinen Eltern, also brauche ich es definitiv nicht von einem LLM. Aber ich mag es, wenn meine Frau das ab und zu tut, und von meinen Kindern auf jeden Fall. Aber unabhängig davon, ja. Diese Vorstellung, dass du hier der Experte bist und mit etwas arbeitest, das weniger Wissen hat als du darüber, was du erschaffen willst, wie es funktionieren soll, wie Erfolg aussieht und wie es in der Vergangenheit gescheitert ist: Behalte einfach diese Denkweise bei. Behalte diese Denkweise bei. Behalte diese Denkweise bei.

[33:12] – Andrew Wertkin: Und dann hast du irgendwann das Gefühl, dass die vier besten Praktikanten der Welt für dich arbeiten, denn für mich sind sie genau das. Vielleicht fünf, manchmal sieben. Aber es ist diese Beschleunigung, die es ermöglicht, das noch heute Abend zu erledigen: „Bitte startet 10 parallele Agenten.“ Ich würde übrigens nicht ‚bitte‘ sagen. „Starte 10 parallele Agenten und führe unser Blitz-Testprotokoll durch.“ Und dann wache ich morgens auf und ein ganzes Team hat die ganze Nacht durchgearbeitet, und ich habe kein schlechtes Gewissen. Ich trinke meinen Kaffee und sehe mir die Ergebnisse an. Das ist sehr beeindruckend.

[33:51] – John Burke: Ja. Und ich glaube, du deutest damit implizit an, was Anbieter wie du tun können, um diese Art von Arbeit in Unternehmensnetzwerken zu unterstützen, und das ist im Grunde genommen die Entwicklung der „Elektrowerkzeuge“, die diese KIs einsetzen können – mit entsprechenden Sicherheitsvorkehrungen. So verfügt die Kreissäge über eine automatische Abschaltung, sodass man sich nicht mehr so leicht die Finger abschneiden kann wie früher. So etwas in der Art. Man möchte ihnen helfen, das Netzwerk nicht zum Absturz zu bringen, indem sie bei der Nutzung Ihrer leistungsstarken Werkzeuge die offensichtlichen Dinge versäumen.

[34:29] – Andrew Wertkin: Ja. Nein, das ist interessant, denn wie die meisten Softwareanbieter heutzutage stellen auch wir unter anderem MCP-Server für unsere Backend-Produkte her, und wir haben mehrere Backend-Produkte. Und ich denke, wie bei vielen Anbietern da draußen war der Ansatz anfangs einfach: „Okay, packen wir unsere OpenAPI-Tools in dieses neue Protokoll, stellen das dann zur Verfügung, und das LLM wird schon damit zurechtkommen.“ Aber man merkt ziemlich schnell, dass das überhaupt nicht der richtige Ansatz ist. Man verschwendet einfach eine Unmenge an Tokens. Es wird jede Menge Rätselraten geben. Man sitzt einfach da und sieht zu, wie das LLM rät und rät und rät.

[35:03] – Andrew Wertkin: Ja, ein LLM kann ziemlich schnell herausfinden, wie man eine REST-API nutzt, und wenn sie in MCP-Tools eingebunden ist, sogar noch schneller. Das bedeutet aber nicht, dass es Ihre Fachdomäne versteht. Und ja, gerade die „Frontier“-Modelle wurden nicht nur auf Ihre Fachdomäne trainiert; sie verstehen wahrscheinlich mehr von Ihrem Produkt, als Ihnen vielleicht bewusst ist.

[35:33] – Andrew Wertkin: Aber ein Teil dessen, was wir liefern, sind nicht nur Tools, die domänenspezifischer sind als eine OpenAPI. Es geht darum, dass zwischen dem MCP-Server und unserem Backend-Server mehr Kommunikation stattfindet, als das LLM sieht. Nehmen wir zum Beispiel eine Paketaufzeichnung: Es gibt keinen Grund, dem LLM eine 20-Megabyte-Paketaufzeichnung zu schicken. Das bringt nichts. Oder ihm eine ganze Zeitreihe zu senden, die man eigentlich an ML senden sollte, nicht an die KI. Wie stelle ich also sicher, dass es die Daten erhält, die es benötigt? Zusammengefasste Daten, vielleicht sogar mit einer gewissen Wertung, denn wir kennen unsere Systeme gut und können so eine Art „Meinung“ einbauen.

[36:15] – Andrew Wertkin: Was braucht das LLM, um die Frage des Nutzers zu beantworten, die vielleicht lautete: „Warum funktioniert das nicht?“ Denkt über diese Dinge nach, anstatt einfach nur … Ich würde das Wort „faul“ verwenden, aber „naiv“ trifft es besser. Es ist naiv, einfach davon auszugehen, dass das LLM das schon gut hinbekommt, vor allem, wenn man will, dass das Ganze auch nur annähernd wiederholbar ist. Also ja, das machen wir, aber es geht um viel mehr als das.

[36:39] – Andrew Wertkin: Nun haben wir gerade die Themen rund um die Softwareentwicklung durchgesprochen, und unsere Kunden können nun Unmengen an Automatisierungsskripten und Ähnlichem für unsere Produkte erstellen. Super. Wie verankern wir die Best Practices dafür, damit unsere Kunden sich nicht selbst in Ausfallzeiten hineinautomatisieren? Damit sie Bescheid wissen. Und das zeigt sich in Dingen wie Netzwerkberatern und anderen Hilfsmitteln – sei es durch Hinweise, spezifischen Code, Funktionen oder Schulungsmaterial –, die unseren Kunden helfen, bei der Automatisierung erfolgreich zu sein. Denn in unserer Branche, insbesondere im DDI-Bereich, in der Welt von DNS und IPAM, war die Automatisierung schon immer der Motor dieser Branche. Man muss diese Dinge schneller ändern. Und deshalb wollen wir, dass unsere Kunden erfolgreich sind.

[37:30] – Andrew Wertkin: Das tut uns weh. Wir hatten vor einigen Jahren, lange vor den LLMs, einen Kunden, und das führt uns zurück zu einem Beispiel dafür, welcher Schaden entstehen kann, wenn es keine Prozesse für die Art und Weise gibt, wie man Software entwickelt. Sie brachten sich quasi selbst bei, wie man Skripte für unser Produkt schreibt, und hatten einen Administrator-Benutzer. Sie schrieben ein Skript, wollten es testen und löschten dabei die gesamte DNS-Umgebung innerhalb dieses Unternehmens, wodurch sie sofort aus den Systemen ausgesperrt wurden. Active Directory war ausgefallen, und sie nutzten es für LDAP, und bla bla bla. Das Glas musste zerbrechen.

[38:05] – Andrew Wertkin: Und sie sitzen da, und ich kann mir das gut vorstellen. Ich habe das schon einmal erlebt. Ich glaube, einmal an der Uni habe ich eine Endlosschleife in eine Anwendung geschrieben, die auf einem alten IBM-PC lief, bei dem man kein Strg+C drücken konnte. Drei Stunden Arbeit, und das Einzige, was ich tun konnte, war, den Computer neu zu starten. Das ist eines von mehreren Beispielen – einige davon aus dem Berufsleben – für dieses Gefühl, bei dem es einem in die Hose rutscht: „Oh Mist.“ [Gelächter] Ja. Und ich kann mir gut vorstellen, was diesem Typen durch den Kopf gegangen ist.

[38:42] – Andrew Wertkin: Und ja, das ist natürlich ein extremes Beispiel, aber mein Punkt ist: Wir werden in der Softwareentwicklung ständig nach Kennzahlen und Messgrößen gefragt, und irgendjemand sagt dann immer: „Na ja, ihr benutzt doch einfach nur Codezeilen oder so“, und das ist so …

[39:00] – Scott Robohn: Das stimmt. Ja. Die Vorstellung, dass für jeden in der Softwareentwicklung die Anzahl der geschriebenen Codezeilen – je mehr, desto besser – eine geeignete Kennzahl ist, ist Wahnsinn.

[39:13] – Andrew Wertkin: Genau. Das machen wir also nicht, und niemand schlägt es vor. Aber mein Punkt ist: Wenn man anfängt, über die richtigen Kennzahlen nachzudenken – sicherlich in der Welt von SaaS, aber mittlerweile auch in der Welt dieser Skripte –, geht es nicht nur darum. Die Frage ist: Hat es so funktioniert, wie wir es erwartet haben? War das eine erfolgreiche Automatisierung? Richtig? Und was haben wir aus dem gelernt, was nicht geklappt hat, und wie lassen wir das wieder einfließen und schaffen eine Feedbackschleife? Ich meine, je weniger Codezeilen zur Lösung eines Problems nötig sind, desto besser – aber vor allem: Hat es das Problem tatsächlich gelöst?

[39:52] – Scott Robohn: Nun, und die geringstmögliche Anzahl an Codezeilen als weitere Kennzahl anzustreben, könnte andere Probleme verursachen, oder? Und noch einmal: Eine der Sachen, die mich an diesem ganzen Umfeld und dieser Diskussion wirklich begeistert, ist, dass die Kunst, unsere Rahmenbedingungen zu definieren, immer wichtiger wird – wahrscheinlich wichtiger als je zuvor in unserer beruflichen Laufbahn, oder? Wir haben Elektrowerkzeuge. Wo bringen wir die richtigen Sägeblattschutzvorrichtungen und den Erdungsstecker an? Mein Großvater hat Elektrowerkzeuge für Porter-Cable hergestellt, und ich besitze tatsächlich einige seiner alten Prototypen, die ich niemals zum Bau einer Terrasse verwenden würde, weil Teile fehlen, die mich davor bewahren, Finger zu verlieren.

[40:27] – Andrew Wertkin: Richtig. Ja.

[40:27] – Scott Robohn: Also das systemische Denken, und es gibt dieses „Stammeswissen“, das jemand anderes …

[40:34] – Andrew Wertkin: [lacht] Auf jeden Fall.

[40:40] – Scott Robohn: John, das könnte in so viele Richtungen gehen. Wohin möchtest du damit?

[40:40] – John Burke: Nun, um das Ganze abzurunden, möchte ich diesen Gedanken weiterführen: Die Verantwortlichen in den Unternehmen müssen ihr Software-Portfolio mittlerweile als leistungsstarke Werkzeuge betrachten, die letztendlich von Roboterhänden und nicht von menschlichen Händen bedient werden, und darüber nachdenken, wie dies die Landschaft der Unternehmenssoftware verändern wird. Wir haben bereits ein wenig darüber gesprochen, wie sich dadurch die Prozesse innerhalb des Unternehmens bei der Nutzung ändern, aber wie sieht es mit dem Rest aus? Ändert sich dadurch die Lizenzierung? Inwiefern verändert das die Dinge noch?

[41:18] – Andrew Wertkin: Auf jeden Fall. Ich denke, ein Teil davon ist das, was man an der Börse und auf den privaten Märkten im Allgemeinen beobachtet hat, nämlich die Abwertung einiger Softwareunternehmen – wobei wir ja alle wissen sollten, dass die Börse eine Welt für sich ist.

[41:33] – John Burke: Ja.

[41:41] – Andrew Wertkin: Aber abgesehen davon wird sich das Lizenzmodell sicherlich ändern. Wenn Ihr Lizenzmodell lediglich auf einer Pro-Benutzer-Basis beruht – und ich sage nicht, dass das daran liegt, dass jeder jeden entlassen wird –, dann frage ich einfach: Okay, was ist ein Agent? Ist ein Agent ein Nutzer? Unternehmen werden herausfinden müssen, was die richtige Kennzahl sein wird. Viele Unternehmen stellen gerade um auf – okay – Credits, und der tatsächliche Wert liegt darin, wie viel man durch dieses LLM verarbeitet hat. Aber Unternehmen mögen keine überraschenden Rechnungen jeden Monat.

[42:20] – Andrew Wertkin: Die legen Wert auf Beständigkeit. Und ich denke, zu Beginn konzentrieren sich vor allem die LLM-Unternehmen selbst oder die KI-Unternehmen selbst ganz offensichtlich sehr stark auf ein undurchsichtiges, kreditähnliches Modell, bei dem wir alle wissen, dass der Preis immer weiter steigen wird. Das werden wir nicht durchziehen können. Netzwerkanbieter werden nicht einfach hingehen und sagen können: „Oh, tut mir leid, Ihre Rechnung ist diesen Monat doppelt so hoch, weil wir das Verhältnis zwischen Credit und Token geändert haben. Und übrigens: Wir haben unser Produkt verbessert, es ist also besser, deshalb müssen Sie mehr bezahlen.“ So funktioniert das in unserer Welt nicht. Also ja, ich denke, die Lizenzmodelle werden sich ändern müssen.

[42:57] – Andrew Wertkin: Aber es geht um so viel mehr als das. Du weißt ja, wie wir immer hin und her schwanken zwischen Plattform und Best-of-Breed, Plattform und Best-of-Breed? Ich glaube, wir werden wieder in Richtung „Best-of-Breed“ tendieren, da die Interoperabilität zwischen verschiedenen Produkten viel einfacher zu lösen ist, insbesondere mit Lösungen wie MCP. Ich glaube nicht unbedingt, dass ich noch eine spezielle Integration in ITSM-Systeme benötige, da alle ITSM-Systeme MCP unterstützen.

[43:43] – Andrew Wertkin: Das erleichtert die Entscheidung zwischen einer Plattform und Best-of-Breed-Lösungen. In bestimmten Bereichen wird das also disruptive Auswirkungen auf Unternehmen haben, deren einziges Ziel darin bestand, so viel wie möglich in ihre Plattform zu packen, sodass niemand mit ihnen konkurrieren konnte. Das wird sich ändern, und ich denke … Soll ich darauf eingehen?

[44:05] – John Burke: Ja.

[44:05] – Andrew Wertkin: Ich mache die 60-Sekunden-… die 30-Sekunden-Version.

[44:10] – Scott Robohn: 30 Sekunden. Ja.

[44:10] – Andrew Wertkin: Ja. Früher war es so, dass in der Welt der großen, unübersichtlichen zentralen Systeme, die niemand ändern konnte – wie zum Beispiel die großen ERP-Systeme –, Unternehmen in ihren Geschäftsberichten sagten: „Wir haben unser Ziel in diesem Quartal verfehlt, weil ein Upgrade dieses riesigen internen Systems schiefgelaufen ist.“

[44:29] – John Burke: Das ist noch gar nicht so lange her.

[44:29] – Andrew Wertkin: Ja, das ist noch gar nicht so lange her. Und genau das war anfangs die gesamte Marketingkampagne von Salesforce, mit dem „Keine Software“ und „Das übernehmen wir für euch“ und all diesen großartigen Versprechungen rund um SaaS.

[44:40] – Andrew Wertkin: In dieser Welt begann die Disruption dieser Systeme dadurch, dass all diese neuen Unternehmen benutzerfreundliche SaaS-basierte Systeme auf den Markt brachten. Die großen Systeme waren zwar nach wie vor die „System of Record“, aber nun gab es dieses neue „System of Engagement“ für das Personalwesen, für das Reisemanagement, für den Einkauf und für jeden anderen Teil dieses Systems. Und dann haben die großen Unternehmen in diesem Bereich natürlich einfach diese Firmen aufgekauft, eine nach der anderen, nach der anderen, nach der anderen. Bis zu einem gewissen Grad bin ich mir nicht ganz sicher, ob es überhaupt zu Übernahmen kommen wird; es wird einfach viel zu viel zu übernehmen geben. Man wird sehen, wie viele Unternehmen Wertversprechen im Stil von „System of Engagement“ für bereits vorhandene Plattformen entwickeln, um nach und nach die Nutzer- oder Systembindung abzuschwächen.

[45:28] – Andrew Wertkin: Und das wird viel schneller passieren als es beim Reisemanagement und bei den Zielen im Personalwesen oder im Einkauf der Fall war – oder bei welchen „Engagement-Systemen“ auch immer, die damit begonnen haben, große interne Systeme zu verändern. In einer Welt, in der es einfacher ist, einen kleinen Teil einer bestehenden Plattform zu revolutionieren – oder zumindest zu verbessern –, wobei die Integration quasi schon vorgefertigt ist, wird uns das meiner Meinung nach wieder zum „Best-of-Breed“-Ansatz zurückführen.

[45:54] – John Burke: Und ich kann mir sogar vorstellen, diesen Weg noch viel weiter zu gehen. Nur die KIs, die für uns arbeiten, verstehen wirklich, wie das Software-Portfolio derzeit aussieht, denn wenn ein neuer Dienst auftaucht, erkennen sie, dass dieser die Hälfte dessen, was sie im Funktionsbereich X tun müssen, besser, schneller und kostengünstiger erledigen kann. Jetzt habe ich also zwei Optionen in diesem Bereich, und die KI entscheidet, welche Aufgabe an welche geht. Es ist so etwas wie ein redundantes Array von Softwareanbietern. Ich nutze einfach die Arbitrage dort, wo es am besten zu den Kriterien passt, die meiner KI zufolge für mich am wichtigsten sind: Zeit sparen, Geld sparen, bessere Leistung, was auch immer.

[46:36] – Scott Robohn: Ja. Interessant.

[46:42] – Andrew Wertkin: Ja. Denn wenn man heutzutage auf eine Tech-Messe geht, insbesondere im Bereich Netzwerke, aber eigentlich in fast jedem technikbezogenen Bereich, sieht man ein Unternehmen nach dem anderen, das seine Plattform für KI verkauft. Egal, woher sie kommen – sie haben jetzt eine KI-Plattform, die herstellerunabhängig sein wird. Warum auch nicht? Jeder hat MCP-Server. Was wird man also als Unternehmen haben? Mehrere Plattformen für agentenbasierte Abläufe? Eine einzige Plattform? Einen Meta-Agenten, der eine Reihe anderer Agentenplattformen verwaltet? Was passiert, wenn ich hier die falsche einsetze, und wie schnell kann ich das ändern?

[47:25] – Andrew Wertkin: Und anscheinend – und diesen Teil verstehe ich nicht, weil es nicht meiner Arbeitsweise entspricht – neigen die Leute auch leicht zu einer Voreingenommenheit: „Oh ja, sie haben gesagt, sie können das alles für mich regeln, also glaube ich ihnen das einfach.“ Und genau darauf läuft es hinaus. Es ist lustig, ich habe vorhin ein konkretes Beispiel genannt: Ich hatte noch nie einen eBPF-Hochgeschwindigkeits-Logger im Kernel-Bereich geschrieben, und jetzt habe ich es getan. Ich könnte immer noch keinen schreiben. Ich habe das als Experiment genutzt: Was passiert, wenn ich diesen Prozess in einem Bereich anwende, in dem ich zwar genau weiß, wie die Dinge funktionieren, aber noch nie tatsächlich Software dafür geschrieben habe? Was werde ich dabei lernen?

[48:05] – Andrew Wertkin: Was ich gelernt habe, war, wie schnell ich etwas umsetzen kann, von dem ich vorher keine Ahnung hatte. Allein durch die Festlegung der Dinge, über die wir zuvor gesprochen haben – wie Kriterien und Abbruchkriterien sowie die Punkte, die mir wichtig sind und mir Sorgen bereiten –, habe ich etwas, das funktioniert. Ich weiß nicht, ob es der beste Weg ist, das Problem zu lösen, mit dem ich angefangen habe. Ich weiß nur, dass es wartbarer Code ist, der funktioniert. Ich meine, ich weiß sogar noch mehr als das: Er ist wirklich gut dokumentiert. Mein Punkt ist also wohl, dass die Leute diese Dinge immer noch lernen müssen, um diese Erfahrung weiterzugeben.

[48:48] – Andrew Wertkin: Und so sehr ich diese Technologie auch schätze, ist das meine größte Befürchtung. Die schlimmsten Fehler entstehen immer dann, wenn jemand glaubt, im Recht zu sein, und die anderen entweder zu eingeschüchtert, zu sehr von ihm beeindruckt, zu ehrfürchtig oder einfach zu faul sind, um die Person zu hinterfragen, die ganz sicher weiß, wie man etwas erledigt. Und das Endergebnis sind Probleme, die hätten verhindert werden können. Das sehen wir überall, von der Technik über soziale Umgebungen bis hin zu allen anderen Bereichen; Gruppendenken oder…

[49:27] – Andrew Wertkin: Aber genau dafür verlasse ich mich auf meine Experten. Selbst wenn es für sie richtig klingt – je richtiger es ihnen sogar erscheint, desto weniger neigen sie dazu, es für bare Münze zu nehmen, denn da muss doch etwas nicht stimmen. Was ist das? Es ist ein Rätsel. In vielen Fällen handelt es sich um Ingenieure. So sehr ich die Technologie auch schätze, nutze, vorantreibe und mit ihr Mehrwert schaffe – es gibt einen Teil daran, der mir einfach Unbehagen bereitet.

[50:12] – John Burke: Ein sehr berechtigter warnender Hinweis, um das Gespräch zu beenden.

[50:12] – Andrew Wertkin: Yeah.

[50:18] – John Burke: Vielen Dank, Andrew, dass du heute bei uns warst. Das war unglaublich interessant, und es gibt viel Stoff zum Nachdenken für Unternehmensstrategen, wenn sie darüber nachdenken, wie es in ihren IT-Abteilungen weitergehen soll. Scott, vielen Dank auch dir, dass du heute bei uns warst. Und wie immer vielen Dank an alle Zuschauer.