Wie KI die Entwicklung von Unternehmenssoftware verändert

HS136 – Gesponsert von Bluecat

[John Burke] (0:00 – 0:05)

Hallo, ich bin John Burke, CTO von Nemertes, und hier bei mir ist mein Co-Moderator.

[Scott Robohn] (0:05 – 0:14)

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

[John Burke] (0:16 – 0:28)

Und Sie hören „Heavy Strategy“, die Sendung, die versucht, die richtigen Fragen zu stellen, statt die richtigen Antworten zu geben. Bei uns zu Gast ist heute Andrew Wertkin, Chief Strategy Officer bei BlueCat Networks. Andrew, vielen Dank, dass Sie bei uns sind.

[Andrew Wertkin] (0:28 – 0:30)

Vielen Dank für die Einladung. Ich freue mich darauf.

[John Burke] (0:30 – 0:52)

Und in der heutigen Sendung werden wir genau darüber sprechen, 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-Leute KI dazu nutzen, die Bemühungen zur Netzwerkautomatisierung 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?

[Andrew Wertkin] (0:54 – 2:08)

Ja, einfach in den permissiven Modus schalten und auf „Los“ klicken. Fertig. Ja, weißt du, es ist interessant, denn, na ja, ich entwickle Software, seit ich denken kann. Weißt du, es gibt einen Grund, warum ich nicht schreiben kann. Ich habe mein ganzes Leben lang getippt. Und diese Arbeit hat mir sehr, sehr viel Spaß gemacht. Aber weißt du, auf der Netzwerkseite war es interessant, weil die Teams wirklich gute Arbeit geleistet haben. Und mit „Teams“ meine ich einfach die Netzwerkingenieure da draußen, die die Automatisierung vorantreiben – also schon vor der Code-Generierung und vor dem Einsatz von Sprachmodellen (LM) – und wirklich versuchen, die Methodik der Softwareentwicklung so zu verfeinern, wie es Softwareentwicklungsunternehmen tun. Und bei KI und bei LM-gesteuertem oder generiertem Code ist es ohne diese Best Practices schon beängstigend, darüber nachzudenken, was im Netzwerk alles passieren könnte. Es läuft also wahrscheinlich auf eine weitere Transformation in diesen Teams hinaus, hin zu ausgefeilteren Prozessen rund um die Softwareentwicklung, denn je schneller Dinge erstellt werden können, desto mehr kann wahrscheinlich auch schiefgehen.

[Scott Robohn] (2:09 – 3:24)

Du hast da eine These, die mich wirklich anspricht, oder? Ich würde sagen, weißt du, eine meiner anderen 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, Deutschland.

Und, weißt du, wir haben diese Diskussion über die Vorbehalte gegenüber der Einführung von Netzwerkautomatisierung schon begonnen, bevor KI ins Spiel kam, oder? Und so gab es schon immer einen gewissen Widerstand dagegen, die Automatisierung auf Hochtouren laufen zu lassen. Und jetzt, weißt du, kommen die Bots und die Agenten ins Spiel, und, na ja, es wird mit den Augen gerollt und die Skepsis ist groß. Ich würde das gerne als Teil unseres Gesprächs hier aufgreifen, um zu sagen: Ich stimme dir zu. Wir müssen sehen, wie sich hervorragende Best Practices in der Softwareentwicklung und im Software-Engineering herausbilden, denn vieles, was wir im Netzwerkbetrieb tun, ist davon abhängig. Ich weiß, dass ich hier vielleicht etwas zu viel Zeit in Anspruch nehme, aber das ist nun einmal meine Sichtweise. Und ich freue mich wirklich darauf, diesen Dialog mit dir zu führen.

[John Burke] (3:24 – 3:42)

Ja, super. Und ich finde, du liegst goldrichtig. Das Misstrauen gegenüber Automatisierung in der Netzwerkbranche reicht 25 Jahre zurück. Ich meine, wir haben schlechte Erfahrungen gemacht. Wir haben schon oft schwer darunter gelitten, dass wir der Automatisierung zu weit und zu schnell vertraut haben.

[Andrew Wertkin] (3:43 – 6:00)

Ja, was ich immer wieder höre, ist Vertrauen – vor allem bei wiederholbaren, vorlagengestützten Aktionen. Ja. Wenn es über das Einfache, Wiederholbare und Vorlagengestützte hinausgeht, dann, ja, dann setzt diese Art von Misstrauen ein, und zwar ziemlich stark. Und, weißt du, wie wir wissen, liebe Kollegen: Wenn ein Anbieter mit dem Slogan „Einfach nur zeigen und klicken“ auftaucht – einfache, unkomplizierte Automatisierung – ist das wahrscheinlich der schlechteste Weg, um das Vertrauen der Endkunden zu gewinnen. Weißt du, je undurchsichtiger es ist, desto größer ist normalerweise die Besorgnis, was, ja, das treibt, es beschleunigt gewissermaßen das Potenzial für Misstrauen in der Welt der KI, weißt du, und ich weiß nicht, nun ja, wir können darüber sprechen, wie man das angehen und mehr Vertrauen schaffen kann, aber das betrifft nicht nur den Netzwerkbereich, sondern ganz offensichtlich alle Bereiche. Viele von uns haben in Umgebungen gearbeitet, in denen keine Quellcodeverwaltung eingesetzt 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 – ich könnte diese Liste endlos fortsetzen.

Und man kann sozusagen 10 dieser größeren Probleme innerhalb eines Tages aufspüren, wenn man den Prozess beschleunigt hat, aber es birgt ein enormes Potenzial. Und es geht nicht nur um Softwareentwicklung, oder? Es geht darum, Fehler zu beheben, herauszufinden, was in Live-Umgebungen vor sich geht und warum es in manchen Bereichen nicht funktioniert. Solange man jemanden mit dem richtigen Fachwissen an seiner Seite hat und dem, was einem gesagt wird, kritisch gegenübersteht, ist die Menge an Arbeit, die in kurzer Zeit erledigt werden kann, einfach – es ist einfach unglaublich, absolut unglaublich. Solange man nicht einfach nur sagt: „Oh, du hast gesagt, es ist so und so, okay, ich sollte dies tun, ich sollte das tun.“ Genau da liegt das Problem, denn wir wissen, dass die LM-Mitarbeiter – so sehr man sie auch dazu anhalten mag, anders zu denken – dazu neigen, die Dinge ziemlich schwarz-weiß zu sehen; sie glauben, sie hätten die Ursache gefunden.“

[John Burke] (6:01 – 6:43)

mir an der Idee der Beschleunigung der Automatisierung gefällt: die Vorstellung, dass man Menschen dabei helfen kann, bewährte Verfahren schneller umzusetzen. Wenn sie diese bewährten Verfahren mit KI nutzen, werden sie ihr Automatisierungsprojekt häufiger zum Abschluss bringen. Sie werden es nicht halbfertig oder zu drei Vierteln fertig lassen, nie vollständig debuggt, nie vollständig dokumentiert. Richtig.

Und dann geht es weiter zum nächsten Notfall. Die Wahrscheinlichkeit ist größer, dass sie es an einem einzigen Tag oder in zwei Tagen oder einer Woche oder zwei Wochen schaffen, den gesamten Prozess durchzuarbeiten und etwas hinterlassen, das sie tatsächlich wieder mit Zuversicht nutzen können – im Gegensatz dazu, dass sie es mit einer gewissen Angst und Zittern tun.

[Andrew Wertkin] (6:44 – 6:58)

Ja, ja. Vieles davon dreht sich einfach um die Architektur. Vieles davon dreht sich um … Nun, zum einen geht es um die richtige Entwickler-Denkweise, nämlich: „Ich schreibe das für die Leute, die es in Zukunft warten werden, also muss ich das im Hinterkopf behalten.“

[Scott Robohn] (6:58 – 7:02)

Das läuft automatisch, oder? Jeder Entwickler denkt vom ersten Tag an darüber nach.

[Andrew Wertkin] (7:02 – 9:15)

Ja, ja, ja, ja, ja. Vor allem, wenn es damit angefangen hat, dass man dachte: „Oh, wir brauchen ein schnelles Skript, um dieses Problem zu lösen.“ Und dann findet das jemand sechs Monate später wieder oder so. Vieles hängt also von der Architektur ab, weißt du – vieles, was in dieser Automatisierung vorkommen wird, wird sich wiederholen, oder? Zum Beispiel: Wie authentifizieren wir uns, oder welche Standards gibt es für die Protokollierung, oder wie wollen wir protokollieren, oder, weißt du, wie werden wir einfach mit unseren Geräten kommunizieren? Wie werden Passwörter verwaltet und wie holen wir diese aus den Tresoren heraus, und, weißt du, 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, ist etwas, das wiederholbar ist und in diese geeignete Methodik passt. Nun muss man im Grunde nur noch seine Geschäftslogik hinzufügen, nicht unbedingt all diese anderen Teile. Und dadurch bleibt der gesamte Code auf dem neuesten Stand, wird getestet und so weiter und so fort. Aber, weißt du, 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 verschiedene, voll funktionsfähige – von A bis Z – Skripte, Anwendungen oder was auch immer wir gerade entwickeln, aus dem Ärmel schütteln. Und deshalb ist es einfach so, dass es, weißt du, ist es wahrscheinlich wichtiger denn je, gleich von Anfang an den richtigen Weg einzuschlagen und darüber nachzudenken, wie wir das Ganze nachhaltig gestalten können und, na ja, wo Menschen in den Prozess eingebunden werden und wo es entscheidend ist, dass sie Teil des Prozesses sind.

Und, weißt du, welche Vorgehensweisen werden wir einführen, um das sicher zu gestalten? All diese Dinge sind einfach – weißt du, viele davon sind genau die Dinge, die wir schon immer berücksichtigt haben oder die uns beim Entwickeln von Software in den letzten Jahrzehnten beschäftigt haben. Richtig. Ein Teil davon liegt einfach daran, wie schnell das jetzt möglich ist. Und es ist nicht so, dass die Leute einfach nur Sachen von Stack Exchange kopieren und einfügen.

[Scott Robohn] (9:16 – 10:33)

Jeder kann Code generieren lassen, der in dieser Umgebung funktioniert, weißt du, das ist ganz einfach, und das war vor zwei Jahren noch nicht der Fall. Ich glaube, wir befanden uns mitten in dieser sich schnell verändernden und experimentellen Zeit, richtig? Wenn man nur ein paar Jahre zurückblickt, hatten die Leute ihre ersten Erfahrungen mit chatbasierten Tools gemacht und dabei sehr unterschiedliche Ergebnisse erzielt. Weißt du, diese ganze Sache mit dem Nichtdeterminismus von LLMs – das waren unsere ersten Erfahrungen. Und dann, weißt du, sehen wir das Aufkommen von „Vibe-Coding“ und erkennen, was für ein Wegbereiter es für das Prototyping ist, aber auch, was für ein Spaghetti-Chaos es in einer Unternehmens-Codebasis verursachen kann – bis hin zu nun aufkommenden Methoden wie der spezifikationsgesteuerten Entwicklung und der testgetriebenen Entwicklung. Ich glaube, wir erleben gerade die Entstehung einer Herangehensweise, bei der es heißt: „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. Richtig. Was beobachtest du in dieser Hinsicht, also was die Entstehung dieser Strategien und wiederverwendbaren Tools angeht, die gerade aufkommen?

[Andrew Wertkin] (10:34 – 11:59)

Ja, nein, wir sehen sie auf jeden Fall und haben bereits mit einigen experimentiert und sie eingeführt. Ich denke, wir – mein Unternehmen und auch ich persönlich – hatten interessanterweise genau in dem Bereich, mit dem ich mich in meiner Karriere wahrscheinlich am wenigsten beschäftigt habe – nicht das Unternehmen, sondern ich persönlich –, nämlich der Entwicklung der Spezifikationen im Vorfeld und der Zusammenarbeit mit dem LLM bei Kompromissen. Genau hier kann ich meine Erfahrung einbringen und mitbestimmen, wie wir vorgehen sollten. Diese Zeit im Vorfeld zu investieren, das Ganze in überschaubare Abschnitte zu unterteilen und dann, die entsprechenden Leitplanken einzurichten – und, wissen Sie, genau diese Art von Vorgehensweise hat einen entscheidenden Unterschied gemacht. Im Gegensatz dazu, dass man versucht, eine Eingabe zu verfassen, die genau beschreibt, was man will, ist es diese Art der iterativen Spezifikations- und Testentwicklung, die wirklich damit beginnt: „Okay, ich möchte einen Hochgeschwindigkeits-TCEBF-Logger erstellen.“ Richtig. Das habe ich noch nie gemacht. Richtig. Und deshalb weiß ich noch nicht einmal, wo die Kompromisse liegen. Und deshalb bin ich mir nicht sicher, wie sehr ich dem Ganzen vertrauen kann. Aber ich kann auf einer sehr hohen Ebene anfangen. Ich möchte das tun. Was weiß ich noch nicht?

[John Burke] (11:59 – 12:47)

Absicht. Du hast es verstanden. Ja. Ich denke, es gibt da einen wirklich wichtigen Punkt, sozusagen eine Ebene darunter, nämlich dass es entscheidend ist, deine Absicht und deinen Bedarf sehr klar zu formulieren, denn wenn Software die Einstellungen an der Hardware in deinem Netzwerk verändert, führt das Verändern der falschen Einstellungen dazu, dass der Datenverkehr zum Erliegen kommt oder die Prozessoren so stark überlastet werden, dass es zu, na ja, schreckliche Leistungseinbußen, da es möglicherweise seine gesamte Zeit darauf verwendet, Protokolle zu erstellen und zu versenden. Man befindet sich also in einem Umfeld, in dem Fehler in der Infrastruktur passieren können – und zwar mit der Geschwindigkeit der Automatisierung –, die wirklich enorme Konsequenzen haben können.

[Andrew Wertkin] (12:47 – 14:57)

Ja. Ja. Ich meine, in unserer DNS-Welt, ich meine, nur auf der öffentlichen Seite: Wenn man sich die letzten großen Ausfälle ansieht, die von riesigen börsennotierten Unternehmen gemeldet wurden, dann waren, glaube ich, 80 Prozent davon automatisierungsgesteuerte Änderungen am DNS, die alles lahmgelegt haben, weißt du, und ich werde einem LLM dafür nicht im Entferntesten die Schuld geben. Das ist einfach… aber je schneller man Lösungen finden kann und je sicherer – insbesondere – dein Programmierpartner oder dein Debugging-Partner, dein Performance-Partner, was auch immer der Anwendungsfall sein mag, je sicherer sie sind, desto wahrscheinlicher ist es, dass du dir sagst: „Okay, weißt du, und dann, weißt du, leiden alle unter dieser „Berechtigungsmüdigkeit“ und so. Du legst einfach den Finger auf die Eingabetaste und drückst immer wieder drauf, weißt du, und so läuft es letztendlich auch darauf hinaus: Wie können wir das Verhalten angemessen überwachen und sicherstellen, dass solche Dinge nicht passieren?

Aber ja, und, weißt du, je erfolgreicher diese Art von „Express Intent“ ist, desto mehr umfasst sie diese Dinge. Weißt du, was könnte potenziell schiefgehen? Was bereitet dir Sorgen? Was stellst du sicher, dass tatsächlich getestet wird? Was bedeutet „Last“ hier eigentlich? Wie sollte es sich verhalten? Nun, du brauchst diese Informationen nicht von vornherein, aber die richtige Erfahrung zu haben, um zu wissen, welche Kategorien von Dingen du wahrscheinlich berücksichtigen solltest, ist gut, weißt du, aber was du 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 einfach, dass du nicht damit anfangen musst, eine vierseitige Anleitung darüber zu schreiben, was genau geliefert werden soll, oder? Das tust du, wenn du ein, na ja, kostengünstigeres Modell mit Laufraten-Charakter verwendest – also kein „Frontier“-Modell –, aber wenn du ein „Frontier“-Modell hast, schreibst du die Spezifikation für das Laufraten-Modell. Weißt du, du wirst beim Erstellen von Prompts niemals so gut sein wie ein LLM.

[Scott Robohn] (14:58 – 15:55)

Stimmt. Also, ich habe eine Technik eingebaut, bei der ich das LLM im Grunde bitte, mich zu befragen, wobei ich, weißt du, eine Seite, eineinhalb Seiten mit einer ziemlich detaillierten Absichtsbeschreibung mitbringe. Und wenn man diesen Prozess nutzt, um all die richtigen Markdown-Dateien für SDD zu erstellen, ist das erstens gü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. Weißt du, der Code ist in gewisser Weise kostenlos, insofern, als wir es gewohnt sind, 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 trotzdem über genügend Fachwissen verfügen, um zu erkennen, dass es sich tatsächlich um Müll handelt, oder?

[Andrew Wertkin] (15:56 – 16:32)

Genau. Und dieser letzte Punkt ist, naja, auf der persönlichen Ebene ist das irgendwie meine Befürchtung, wie das alles in 10 Jahren aussehen wird, aber es ist auch das Entscheidendste im Moment: Ohne das Fachwissen und die Erfahrung und Expertise darüber, wie Dinge scheitern können und wie sie funktionieren sollten und wie sie auf elegante Weise scheitern sollten und so weiter und so fort – dann, dann bittet man geradezu um Ärger. Aber ja, das gefällt mir, und ich gehe dabei wahrscheinlich weniger streng vor als du. Aber so in der Art: „Weißt du, woran denke ich hier gerade nicht?“ Genau. Was könnte hier noch schiefgehen?

[John Burke] (16:33 – 16:53)

Und wenn die LLMs dir genauso gerne den, na ja, tödlich giftigen Pilz präsentieren wie den leckeren und essbaren Pilz, und sie bei flüchtiger Betrachtung gleich aussehen. Ja, diese Art von Fachwissen wird unersetzbar und absolut notwendig.

[Andrew Wertkin] (16:54 – 20:08)

Ja. Und Folgendes passiert, und deshalb ist der Prozess hier so wichtig: Die Leute setzen sich hin und glauben, sie seien mit dem LLM auf einer Wellenlänge. Und, weißt du, über ein paar Wochen hinweg scheint das auch zu stimmen – es scheint sich an Dinge zu erinnern. Und dann, weißt du, am siebten Tag startest du eine neue Sitzung und scheinbar hat es alles vergessen, was es jemals gewusst hat. Und es hat sich im Laufe der Woche irgendwie verschlechtert, weil du das nicht dokumentiert hast. Du hast es versäumt, die entsprechenden Erinnerungen zu speichern und sicherzustellen, dass du deine Prompts und alles andere aktualisierst. Und dann trifft es eine Entscheidung, die unglaublich naiv ist. Und man – weil wir diese Dinge vermenschlichen – hat diesen Gedanken: „Arbeite ich etwa mit einem Doppelgänger zusammen? Oder wer ist diese Person, mit der ich hier arbeite?“ „Wie ist es möglich, dass es das vergessen hat?“ Und so treten in solchen Momenten viele Fehler auf, wenn der Bediener, der Entwickler, der Netzwerkbetreiber – wer auch immer das System nutzt – sich über den Speicherstatus der Sitzung 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, na ja, Überraschung – wie nennen wir das noch gleich? Ein Teil davon ist sozusagen die „Wiederentdeckungssteuer“. Also werde ich 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. Und das sind Dinge, die die großen Modelle im Allgemeinen tun – aber das hängt natürlich vom jeweiligen Programmierwerkzeug ab. Ich nutze zwar meistens Claude, aber unabhängig davon gibt es mehrere. Sie sind wirklich gut darin, mich am Ende jeder Sitzung zu fragen: „Was haben wir gemacht?“ Was musstest du neu entdecken und was musstest du neu entdecken? Sollten wir das angemessen dokumentieren, damit du es nicht noch einmal neu entdecken musst? Und das ist noch nicht alles, denn, weißt du, Experimentieren funktioniert. Manchmal lernt man eine Menge, wenn man Fehler macht, weißt du, und vielleicht ist der Rückgriff auf die persönliche Seite immer noch die professionelle Seite von sozusagen „abgehärteter“ Software – also Software, die funktioniert, wie wir sagen, die auch unter Druck funktioniert und nicht nur im Labor. Sie funktioniert nicht nur in den „glücklichen Fällen“, sondern auch unter Druck – sie funktioniert einfach weiter. Und, weißt du, um an diesen Punkt zu gelangen, braucht es Erfahrung damit, es schon einmal gemacht zu haben, aber insbesondere damit, dabei gescheitert zu sein – es ist so, als ob etwas nicht stimmt, weil man diesen Fehler schon einmal gemacht hat oder dabei war, als es passierte. Und diese Art des Lernens, die, weißt du, ganz spezifisch für die sehr großen Kontextumfänge unseres Gehirns ist, ist so, als müsstest du nicht einmal deine Notizen durchgehen. Man erkennt dieses Muster sofort, wenn man die Erfahrung des Scheiterns gemacht hat – es ist einfach fest verdrahtet, und das sind Dinge, von denen ich einfach nicht weiß, wie sie ohne Absicht, ohne Zweck geschehen sollen.

[John Burke] (20:09 – 21:10) Und ich höre manchmal Leute sagen, dass es nicht mehr lange dauern wird, bis, na ja, wir diese Skripte oder Programme gar nicht mehr selbst entwickeln, sondern die KI das für uns übernimmt. Wir sagen ihr einfach, was passieren soll. Sie wird im Hintergrund ein Programm starten, es losschicken und die Sache erledigen. Und wenn wir es das nächste Mal brauchen, wird sie ein Programm generieren und es zur Ausführung losschicken, und schon sind wir fertig. Es ist also so, als würde sie die Automatisierung für uns schaffen. Sie wird die Automatisierung sein. Sicher. Und für mich klingt das, was du gerade sagst, nach einem Einwand dagegen. Es ist so: OK, 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 dann daran erinnern, wie es das Problem beim letzten Mal gelöst hat?

Wird es sich merken, was schiefgelaufen ist und wie es behoben wurde? Vielleicht, vielleicht auch nicht. Ich denke, bis dieses Problem gelöst ist – und zwar durch Lösungen, die auch im Ernstfall funktionieren, wie du sagst: Egal, wie wütend ich bin, wenn ich die Eingabeaufforderung an die KI tippe, wird sie mir trotzdem die richtige und die gute Antwort geben. Dann ist es noch nicht gelöst.

[Andrew Wertkin] (21:11 – 24:34)

Und ja, dann ist es noch nicht gelöst. Und das Einzige, was ich dem noch hinzufügen wollte, ist, dass man auf das gegenteilige Problem stößt, nämlich, ähm, weißt du, weil die Elemente im Grunde Mustern entsprechen. Äh, und wenn also etwas so aussieht, als würde es zu diesem Muster passen, heißt das noch lange nicht, dass das die Antwort ist. Und ironischerweise, wenn man zum Beispiel nur ein paar Fälle dieser Art hat, bei denen, na ja, etwas ist fehlgeschlagen, und hier ist der Grund, warum ich das Muster kenne – dann ist es umso wahrscheinlicher, dass man etwas gewissermaßen, na ja, gewaltsam in dieses Muster hineinzwängt, so als würde man den runden Pflock in das quadratische Loch hämmern, wenn er fast passt, verstehst du? Und, äh, und es ist einfach so, ich glaube, es gibt immer noch eine gewisse Kluft zwischen, ähm, vor allem in der Welt von Brownfield, aber, aber, äh, zwischen, na ja, ich werde einfach meine Absicht formulieren und die Skripte werden geschrieben, die Dinge werden erledigt. Ich muss mir das nie zweimal ansehen. Ähm, damit das tatsächlich in einem Unternehmensnetzwerk umgesetzt wird, wo, ähm, man heute noch nicht über alle Tools verfügt, um das zu bewerkstelligen. Ähm, man hat heute nicht unbedingt das Budget, um das zu realisieren. Ähm, und man hat eine Vorgeschichte. Und zu dieser Vorgeschichte gehören Dinge, die in der Welt der KI nicht gut sind, nämlich Dinge wie „Tribal Knowledge“ und Sonderfälle. Und, weißt du, das wurde aus einem ganz bestimmten Grund so gemacht, aber es ist sozusagen mit gelbem Absperrband umwickelt. Niemand weiß warum, aber wir wissen einfach: Wenn wir es ändern, geht alles kaputt. Also, also ändern wir nichts mehr. Weißt du, es wurde einfach nie dokumentiert – das wurde nicht dokumentiert. Also, ähm, weißt du, ich greife einfach wieder auf eines der, ähm, wirklich bekannten, ähm, Standardwerke der Softwareentwicklung zurück, bei dem sich zwar die Werkzeuge und Taktiken geändert haben, dieses Buch aber nach wie vor genauso zutreffend ist wie eh und je, äh, Martin Fowlers „Refactoring“, in dessen Vorwort, also in den ersten paar Absätzen, es, glaube ich, heißt: „Wenn du es nicht testen kannst, leg dieses Buch zurück ins Regal“ – ähm, ich paraphrasiere das, aber so in etwa, dass man es nicht ändern kann, wenn man es nicht testen kann. Und in dieser Welt von, ähm, na ja, Stammeswissen und Sonderfällen, in der nicht alles einem Muster folgt, ähm, wie, wie willst du das angehen, ähm, vor allem, wenn es nichts gibt, womit du es testen kannst – dein Labor hat diese Sonderfälle nicht, weißt du, die Frage ist: Wie testen wir das eigentlich angemessen? Und, und, und genau das ist der Grund für diesen ganzen, na ja, längeren Change-Management-Prozess. Sie wissen aus Erfahrung, dass es kaputtgeht, wenn wir daran rühren. Das wird also nur in so einem Änderungsfenster passieren, in dem wir dreieinhalb Stunden Zeit haben und während dieses Zeitfensters nichts anderes eingeplant werden kann – und obwohl sie das zugrunde liegende Problem nie behoben haben, haben sie es einfach in den Prozess eingebunden. Und deshalb, weißt du, müssen Unternehmen – auch große Konzerne – sich überlegen, wo sie bei dieser Sache anfangen sollen. Ähm, und, um das Offensichtliche zu sagen, ähm, äh, das Wichtigste ist, äh, weißt du, von Anfang an so zu bauen, dass es gut funktioniert, ähm, etwas Bestehendes zu ändern, sei es Software oder eine Netzwerkarchitektur, ähm, das ist für Menschen und LLMs viel schwieriger, äh, aber zumindest auf der menschlichen Seite verfügen die Menschen hoffentlich über etwas von diesem „Stammeswissen“.

[Scott Robohn] (24:35 – 26:08)

Eine der – also eine weitere spannende Sache, die meiner Meinung nach vor uns liegt, ist, weißt du, genau das, was du gerade dargelegt hast. Ähm, weißt du, wenn ich ein LLM habe, sieht alles wie eine Eingabeanweisung aus, oder? Und wir – ich glaube, viele von uns – erkennen gerade, dass nicht alles ein Problem für ein LLM ist. Und 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 zum Beispiel immer noch sehr nützlich für andere Dinge im KI-Bereich, und statistische Regression kostet mich, soweit ich weiß, keine Tokens. Richtig.

Stimmt. Ich erweitere also meine Toolbox, und die wirklich spannende Herausforderung, die vor uns allen liegt, besteht darin, die richtigen Werkzeuge für die jeweilige Aufgabe einzusetzen. LLMs dort, wo sie Sinn machen, ML dort, wo es Sinn macht, Regression dort, wo es Sinn macht, ähm, vielleicht für das, das, das Problem, das du angesprochen hast – nämlich, dass man jedes Mal, wenn die Frage gestellt wird, das Rad neu erfindet –, vielleicht sind ein Teil meiner Einschränkungen: 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. Und ich, ich improvisiere hier gerade ein bisschen, oder? Aber ich denke, das sind alles Ansätze, die wir auf den Tisch bringen müssen, während wir gemeinsam versuchen, das Ganze zu klären.

Und ich stehe dem Ganzen viel positiver gegenüber, als dass ich zynisch wäre. Ähm, frag mich in einem Jahr noch einmal, ob ich dann immer noch so denke.

[Andrew Wertkin] (26:08 – 30:11)

Also, nein, es ist interessant, was diese Art von Servicekatalog angeht. Ich meine, das Gute daran ist, dass man das LLM einfach überprüfen lässt, ob man das Problem schon einmal gelöst hat, weißt du, und, äh, und sie sind wieder super gut darin, Muster abzugleichen – sie werden etwas finden. Und das ist eigentlich sozusagen bei 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, ist, ähm, ist, ist, ist super – sowohl aus der Perspektive von, na ja, es ist, es ist, es ist eine kurze Geschichte. Vor vielen, vielen Jahren war ich CTO eines Unternehmens im Bereich Application Lifecycle Management. Wir haben also Software entwickelt, die beim Erstellen von Software helfen sollte, und insbesondere … ähm … ein Teil unserer, sozusagen, idealen Kundschaft kam aus dem Bereich der eingebetteten Software, die sicherheitsrelevant war – wo, ähm, ein Fehler dem Bediener Schaden zufügen könnte, zum Beispiel, ähm, in der Automobilindustrie oder, na ja, was auch immer. Und in dieser Welt gibt es also alle möglichen Standards wie ISO 26000 und, äh, Automotive SPICE und so weiter und so fort. Und ein Teil dieser Standards besagt, dass eine Rückverfolgbarkeit zwischen Anforderungen und Code gegeben sein muss. Richtig. Ähm, und wenn sich die Anforderungen oder der Code ändern, wird diese Rückverfolgbarkeit, ähm, potenziell problematisch. Und ich muss dann nach all diesen Auswirkungen suchen und bei dieser Änderung feststellen: „Übrigens, ich habe den Code geändert, aber die Anforderung ist immer noch korrekt.“ Der Testfall ist immer noch korrekt. Die Architektur ist immer noch korrekt. Das muss ich dann für alle diese verdächtigen Verknüpfungen tun. Ähm, und man wird jemanden, der, ähm, B2B-Software entwickelt, nicht davon überzeugen können, dass er dieses Maß an Rückverfolgbarkeit braucht. Richtig. Aber ich mache das, wenn ich LLM-basiert entwickle, weil es einfach großartig ist – zum einen, weil es mir größtenteils Spaß macht, aber auch, weil das LLM dann die Rückverfolgung übernimmt. Ähm, und das LLM kann schnell herausfinden, warum wir etwas so gemacht haben, wie wir es gemacht haben, weil es bis zur Dokumentation zurückverfolgen kann und, und, und das LLM, das diese Dokumentation verfasst hat, und das LLM weiß, wie es die Dokumentation für sich selbst schreibt, was etwas ist, das, weißt du, naja, ähm, äh, selbst wenn ich manchmal sage: „Schreib das für einen Menschen“, schreibe ich es manchmal so, weißt du, als würde ich dieses Dokument für einen Kunden verfassen, der vielleicht keine Ahnung von Softwareentwicklung hat, nicht weiß, wie Softwareentwicklung funktioniert, oder vielleicht noch nie Python installiert hat – was auch immer der Fall sein mag. Ähm, aber oft füge ich bei diesen Dokumenten entweder einen Anhang speziell für ein LLM hinzu oder schreibe es einfach direkt für ein LLM, und, ähm, erstens ist es prägnanter, aber zweitens, na ja, sind LLMs ziemlich gut darin, Dokumente zu verfassen, die sie selbst lesen können, und, äh, und, ähm, weißt du, sowohl aus Effizienz- als auch aus Kostengründen, wenn man es liest, richtig. Weißt du, die menschliche Version ist teurer, aber unabhängig davon führt das auch zu folgendem Punkt: Okay, jetzt habe ich die richtige Software integriert, damit die nächste Person sie pflegen kann, und auch Software für das nächste LLM geschrieben, das diese pflegen soll. Ähm, und angesichts der Tatsache, dass es offensichtlich in der Lage ist, schnell große Textmengen einzulesen und zu analysieren, ähm, ja, ich hatte noch nie eine bessere Dokumentation in meinem Code oder außerhalb meines Codes. Ähm, als Mensch hätte ich niemals so viel Dokumentation erstellt. Ähm, niemals, äh, weißt du, mit der Annahme, die die meisten Menschen haben, dass man sich beim Schreiben denkt: „Äh, ja, daran werde ich mich erinnern. Ja, das ist ziemlich leicht zu lesen. Ich lese einfach den Code, als wäre es offensichtlich oder jeder würde verstehen, was ich damit gemeint habe.“ Ja, genau. Ja. Ich habe gesagt: „Sortieren“, ich sortiere hier, weißt du, und, ähm, und dass diese Dinge zu einer enormen Anzahl von Fehlern führen, aber das tut auch, ähm, äh, das, weißt du, manchmal sogar noch schlimmer – ich meine, wie lautet das alte Sprichwort? So in der Art: Das Einzige, was schlimmer ist als, ähm, keine Internetverbindung, ist eine miese Internetverbindung. Genau.

Ja. Genau. Bei der Dokumentation ist es genauso.

[John Burke] (30:11 – 30:48)

In gewisser Weise, ähm, betreust du also deine KI, um ihre Fachkompetenz zu verbessern. Du bringst ihr mehr darüber bei, was es bedeutet, ein physisches Netzwerk aus physischen Geräten zu betreiben, welche Risiken bestehen und, äh, wo die Grenzen des Experimentierens liegen und so weiter. Äh, und gleichzeitig bringen Sie ihr bei, ein gutes Teammitglied zu sein, indem sie beispielsweise ihren Code dokumentiert und ihre Vorgehensweise klar erläutert.

[Andrew Wertkin] (30:48 – 32:30)

Nein, das ist eine gute, das ist eine gute Analogie, denn, ähm, das ist es, was ich den Leuten normalerweise, äh, rate, so wie, ähm, ja, besonders wenn sie, sie sind erfahrene Entwickler, also, ähm, ja, stell dir einfach vor, du hast vier junge bis mittel erfahrene Softwareentwickler, die mit dir zusammenarbeiten und, ähm, die ziemlich selbstbewusst sind, weißt du, die davon überzeugt sind, dass sie Recht haben, verstehst du? Und wenn einer von ihnen zu dir sagen würde: „Nein, nein, das ist 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?“ Und wenn du deine Interaktionen so betrachtest, dann wirst du immer darüber nachdenken, was die richtige Frage ist – auch wenn es um die Fähigkeit geht, schnell funktionierenden Code zu schreiben, weißt du, das ist kein Junior- oder fortgeschrittener Softwareentwickler, aber was den Denkprozess angeht, ähm, ja, haben fortgeschrittene Softwareentwickler in vielen Fällen, ähm, einen besseren Denkprozess, weißt du, mit anderen Worten, denn es geht um den Denkprozess, es geht nicht um Mustererkennung und, ähm, die anderen „Zaubertricks“ von großen Sprachmodellen. Ähm, und so in der Art, ich denke, das ist der größte Fehler, äh, den die Leute machen, weißt du, ob es nun Vorurteile sind, also Bestätigungsfehler oder sonst etwas – die Leute suchen nach, ähm, dieser Art von positiver Antwort: „So werden wir es machen.“ Und, äh, und wenn sie sagen: „Hey, ich habe darüber nachgedacht, das ist eine gute Idee.“ Das wissen wir doch alle. Ähm, das ist die schlechteste Art, mit einem LLM zu interagieren, denn es wird dir freudig antworten: „Brillant. Wow.“

[Scott Robohn] (32:31 – 32:39)

Ja. Du bist so schlau. Das ist die beste Art und Weise, wie ich es je gehört habe. Ja. Füge einfach bei jedem deiner Probleme keine Schmeichelei ein.

[Andrew Wertkin] (32:39 – 33:53)

Ja, nein, mach das auf jeden Fall. Denn ich, ich, ich brauche das nicht von meinen Kollegen, meinen Mitarbeitern und meinen Eltern. Von einem LLM brauche ich das definitiv nicht, aber, ähm, für meine Frau finde ich es ab und zu ganz gut. Ähm, aber, aber unabhängig davon, und meine Kinder auf jeden Fall, aber unabhängig davon, ja, nein, es ist, aber diese Vorstellung, dass du sozusagen der Experte bist und mit, ähm, äh, etwas zusammenarbeitest, das weniger Wissen hat als du darüber, was du erschaffen willst und wie es funktionieren soll und wie Erfolg aussieht und wie es in der Vergangenheit gescheitert ist. Und behalte einfach diese Denkweise bei, behalte diese Denkweise bei, behalte diese Denkweise bei. Und dann hast du irgendwann das Gefühl: Das ist so, als ob Ich habe die vier besten Praktikanten der Welt, die für mich arbeiten“, denn für mich bedeutet das mit dem LLM – vielleicht fünf, manchmal sieben –, aber es ist, weißt du, ähm, äh, die Beschleunigung, das heute Abend noch hinzubekommen: „Bitte starte 10 parallele Agenten.“

Ich würde übrigens nicht sagen: „Bitte, 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 gearbeitet und, äh, ich, ich habe kein schlechtes Gewissen. Ich habe kein schlechtes Gewissen, weißt du, ich trinke meinen Kaffee und gehe die Ergebnisse durch – das ist wirklich beeindruckend.

[John Burke] (33:53 – 34:32)

Und du sagst damit, glaube ich, implizit, was Anbieter wie du tun können, um diese Art von Arbeit in Unternehmensnetzwerken zu unterstützen, und zwar im Grunde genommen die Entwicklung der „Kraftwerkzeuge“, die diese KIs mit entsprechenden Sicherheitsfunktionen einsetzen können. Also, weißt du, die, die, äh, Kreissäge hat eine automatische Abschaltung, sodass man sich nicht mehr so leicht die Finger abschneiden kann wie früher – solche Dinge eben. Äh, man möchte ihnen helfen, das Netzwerk nicht zum Absturz zu bringen, indem sie es versäumen, die naheliegenden Dinge mit ihren Werkzeugen zu tun.

[Andrew Wertkin] (34:32 – 39:51)

Ja. Nein, das ist interessant. Denn, weißt du, die meisten, ähm, Softwareanbieter stellen heutzutage unter anderem unsere MCP-Server für unsere Backend-Produkte her.

Und wir haben mehrere Backend-Produkte und, ähm, ich denke, wie bei vielen Anbietern da draußen war es anfangs einfach so: „Okay, lasst uns unsere Open-API-Tools und dieses neue Protokoll bündeln. Und das stellen wir dann einfach zur Verfügung, und, na ja, das LM wird es schon herausfinden.“ Und man merkt ziemlich schnell, dass, ähm, das überhaupt nicht der richtige Ansatz ist. Man verschwendet einfach eine Menge Tokens. Es kann eine Menge Rätselraten sein. Man sitzt einfach da und sieht zu, wie das LM rät und rät und rät. Und, ähm, na ja, man kann zwar ziemlich schnell herausfinden, wie man eine REST-API nutzt. Und wenn sie in, äh, MCP-Tools eingebunden ist, geht es sogar noch schneller, aber das bedeutet nicht, dass sie deine Domäne verstehen. Und ja, vor allem die „Frontier“-Modelle wurden nicht nur auf deine Domäne trainiert, sondern verstehen wahrscheinlich mehr von deinem Produkt, als dir vielleicht bewusst ist. Ähm, aber, aber keines davon, ähm, ist Teil dessen, was wir liefern – es geht nicht nur darum, ähm, weißt du, äh, mehr, äh, domänenspezifische Tools als eine offene API zu haben. Es findet zum Beispiel mehr Kommunikation zwischen dem MCP-Server und unserem Backend-Server statt, als das LM sehen muss. Schickt nicht, äh, es gibt da ein Beispiel für eine Paketaufzeichnung. Es gibt keinen Grund, dem LM eine 20-Megabyte-Paketaufzeichnung zu schicken, die nichts bewirkt, oder ihm eine ganze Zeitreihe zu senden, die man eigentlich an, äh, ML schicken sollte, nicht an KI, weißt du, Also, wie bekomme ich die benötigten Daten – zusammengefasste Daten, vielleicht sogar mit einer gewissen Wertung, weil wir unsere Systeme gut kennen, also mit einer Art eingebauter Einschätzung. Was braucht das LM, um die Frage des Nutzers zu beantworten, die vielleicht so gelautet hat: „Warum funktioniert das nicht?“, und diese Dinge zu durchdenken, anstatt einfach – es ist ein bisschen, ich werde das Wort „faul“ verwenden, aber es ist „naiv“. Ich glaube, das ist das passendere Wort. Es ist naiv, einfach davon auszugehen, dass die Sprachmodelle diese Dinge gut herausfinden werden. Und vor allem, wenn man will, dass das Ganze auch nur annähernd wiederholbar ist. Ähm, also ja, das machen wir, aber es geht um viel mehr als das. Wir haben uns gerade mit Softwareentwicklung beschäftigt. Und ja, unsere Kunden können jetzt Unmengen an Automatisierungsskripten für unsere Produkte erstellen – super. Wie kodieren wir die Best Practices dafür? Damit unsere Kunden sich nicht, weißt du, durch Automatisierung in, ähm, Ausfallzeiten manövrieren. Damit, äh, damit sie Bescheid wissen, und das zeigt sich in Dingen wie, weißt du, äh, Netzwerkberatern und anderen Dingen, die, die, ähm, sei es durch Eingabeaufforderungen oder, äh, spezifischen Code oder Funktionen oder Schulungsmaterial, sozusagen, 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 der Rückenwind dieser Branche schon immer die Automatisierung. Man muss die Dinge schneller ändern. Und deshalb, ähm, wollen wir, dass unsere Kunden erfolgreich sind. Es, es schmerzt uns. Ähm, wir hatten vor einigen Jahren einen Kunden, lange vor den LMs, und das führt mich zurück zu einem Beispiel dafür, wie, ähm, schrecklich es werden kann, wenn es keine Prozesse für die Softwareentwicklung gibt: Er brachte sich quasi selbst bei, wie man Skripte für unser Produkt schreibt. Er hatte einen Administrator-Zugang, schrieb ein Skript, wollte es testen und löschte dabei die gesamte DNS-Umgebung des Unternehmens, wodurch er sofort aus den Systemen ausgesperrt wurde. Active Directory fiel aus – sie nutzten es für LDAP und so weiter und so fort –, und es musste einfach etwas kaputtgehen. Und so war es, und er saß da, ähm, ich kann mir das gut vorstellen – ich habe das auch schon erlebt, weißt du, ähm, ich glaube, einmal an der Uni habe ich eine Endlosschleife in eine Anwendung geschrieben, die auf so einem alten IBM-PC lief, wo es keine Möglichkeit gab, den Startwert zu kontrollieren. Man konnte nicht einfach, na ja, drei Stunden Arbeit. Das Einzige, was ich tun konnte, war, den Computer neu zu starten. Weißt du, ich kenne das irgendwie, das ist eines von mehreren Beispielen – manche davon beruflicher Natur –, dieses Gefühl, als würde man sinken, so nach dem Motto: „Oh Mist.“ Ja, wir, wir haben, und ich kann mir vorstellen, was diesem Typen durch den Kopf gegangen ist, weißt du? Und, ähm, also, ja, das ist natürlich ein extremes Beispiel, aber mein Punkt ist, ähm, je mehr wir, ähm, wir werden in der Softwareentwicklung immer gefragt, äh, nach Metriken und Messgrößen, und irgendjemand sagt dann immer: „Na, warum nehmt ihr nicht einfach die Anzahl der Codezeilen oder so?“ Und das ist ja so: Für jeden in der Softwareentwicklung ist die Vorstellung, dass die Anzahl der geschriebenen Codezeilen – je mehr, desto besser – eine geeignete Metrik ist, einfach Wahnsinn, oder? Das machen wir also nicht und empfehlen es auch nicht. Aber mein Punkt ist: Wenn man anfängt, über die richtigen Kennzahlen nachzudenken – nun ja, sicherlich in der Welt von SAS, aber mittlerweile auch in der Welt solcher Skripte –, geht es einfach nicht nur um die Frage: Hat es so funktioniert, wie wir es erwartet haben? War das eine erfolgreiche Automatisierung? Ähm, und was haben wir daraus gelernt, was nicht geklappt hat? Und wie lassen wir das wieder in einen Feedback-Kreislauf einfließen? Und, ähm, es ist nicht so, dass – na ja, ich meine, ich dachte früher: Je weniger Codezeilen zur Lösung eines Problems, desto besser. Aber hat es das Problem tatsächlich gelöst?

[Scott Robohn] (39:52 – 40:36)

Nun, wenn man, weißt du, die möglichst wenige Codezeilen anstrebt, könnte das, im Gegensatz zu anderen Ansätzen, ähm, andere Probleme verursachen, oder? Und, noch einmal, eines der Dinge, die mich an dieser ganzen Umgebung und Diskussion wirklich begeistern, ist, dass die Kunst, unsere Einschränkungen zu spezifizieren, viel wichtiger wird, ähm, wahrscheinlich wichtiger als jemals zuvor in unserer Karriere, oder? Weißt du, wir haben Elektrowerkzeuge – wo bringen wir die richtigen Sägeblattschutzvorrichtungen an? Und es gab Schutzstecker. Ähm, mein Großvater hat Elektrowerkzeuge für Porter Cable hergestellt. Und ich habe tatsächlich einige seiner alten Prototypen, die ich niemals zum Bau einer Terrasse verwenden würde, weil Teile fehlen, durch die man ständig Finger verliert. Richtig. Es geht also um systemisches Denken, ähm, und um „Stammeswissen“.

[Andrew Wertkin] (40:36 – 40:39)

Weil, ja. Jemand anderes kann, äh, das war richtig.

[Scott Robohn] (40:39 – 40:44)

Auf jeden Fall, John, das könnte in so viele Richtungen gehen. Also, wohin willst du damit?

[John Burke] (40:44 – 41:20)

Nun, ich denke, um das Ganze abzurunden, möchte ich diesen Gedanken weiterführen, dass, äh, die Leute in der Branche jetzt darüber nachdenken müssen, ihr Software-Portfolio als leistungsstarke Werkzeuge zu betrachten, die letztendlich von Roboterhänden und nicht von menschlichen Händen bedient werden. Und, ähm, wie das die Landschaft der Unternehmenssoftware verändern wird. Wir haben ja schon ein wenig darüber gesprochen, wie sich dadurch die Prozesse im Unternehmen bei der Nutzung verändern, aber wie sieht es mit dem Rest aus?

Ähm, ändert sich dadurch die Lizenzierung? Ändert sich, äh, weißt du, wie auch immer die Dinge sicher ablaufen.

[Andrew Wertkin] (41:20 – 44:13)

Und ich denke, ich meine, weißt du, ein Teil davon ist sozusagen das, was du auf den privaten Märkten im Allgemeinen beobachtet hast, mit, ähm, der Abwertung einiger Softwareunternehmen, was, äh, na ja, wir sollten alle wissen, dass der Aktienmarkt sein eigenes Ding ist. Das ist eine Sache für sich. Ja. Äh, aber abgesehen davon, ähm, wird sich das mit Sicherheit auf die Lizenzmodelle auswirken. Ähm, ich meine, wenn dein Lizenzmodell nur auf einer Pro-Benutzer-Basis beruht – und ich sage das nicht, weil alle in Schwierigkeiten stecken, ich sage nur: Okay, ein Agent ist ein Benutzer. Und, und, ähm, äh, weißt du, es, es, es, ja.

Unternehmen werden herausfinden müssen, ähm, weißt du, was die richtige Kennzahl sein wird. Und, wissen Sie, viele Unternehmen stellen gerade um auf – okay – Credits. Und darin liegt der eigentliche Wert: Wie viel man über dieses LM abgewickelt hat, und, und, Unternehmen mögen ja keine überraschenden Rechnungen jeden Monat.

Ähm, sie, sie mögen Konsistenz, weißt du? Und deshalb, ähm, denke ich, äh, weißt du, dass junge Unternehmen, insbesondere die LM-Unternehmen selbst oder die KI-Unternehmen selbst, offensichtlich sehr auf eine Art undurchsichtiges Kreditmodell fokussiert sind, ähm, bei dem wir alle wissen, dass der Preis immer weiter steigen wird. Wir werden die Netzwerkausrüster nicht mehr bedienen können.

Man kann da nicht einfach reingehen und nach oben gehen. Tut mir leid, deine Rechnung diesen Monat beträgt, ähm, ja, sie ist diesen Monat doppelt so hoch, weil wir ja das Verhältnis zwischen, ähm, Guthaben und Token geändert haben. Und, äh, und übrigens, äh, haben wir unser System verbessert. Es ist also besser. Also wirst du mehr bezahlen. So funktioniert das in unserer Welt einfach nicht. Und deshalb, ja, ich glaube, Lizenzmodelle werden sich ändern müssen. Und, ähm, äh, äh, aber es geht um so viel, so viel mehr als das. Ich glaube, es wird – ich glaube, wir haben jetzt die Gelegenheit, weißt du, wie wir immer irgendwie zwischen „Plattform“ und „Best-of-Breed“ hin und her schwanken. Ich glaube, wir werden wieder in Richtung „Best-of-Breed“ gehen, weil die Interoperabilität zwischen diesen verschiedenen Produkten mittlerweile, ähm, viel einfacher zu lösen ist. Ähm, besonders bei Dingen wie MCP – ich glaube nicht unbedingt, dass ich noch eine spezielle Integration zu, äh, ITSM-Systemen brauche, weil alle ITSM-Systeme, äh, MCP unterstützen. Und so, ähm, wird es einfacher, äh, sich zwischen einer Plattform und Best-of-Breed-Lösungen zu entscheiden, aber, aber in bestimmten Bereichen wird das für Unternehmen disruptiv sein, bei denen, na ja, wenn ihr einziges Ziel darin bestand, so viel wie möglich in ihre Plattform zu packen, äh, und niemand mit uns konkurrieren kann, äh, das wird sich ändern. Ähm, weißt du, und, äh, und ich denke, soll ich damit anfangen? Ja, ich mache die 60-Sekunden- und die 30-Sekunden-Version.

[Scott Robohn] (44:13 – 44:13)

30 Sekunden.

[Andrew Wertkin] (44:14 – 44:29)

Ja. Ja. Früher war es so in der Welt der großen, hässlichen zentralen Systeme, die niemand ändern kann, wie die großen ERP-Systeme und so weiter, wo Unternehmen dann in ihrem Geschäftsbericht schreiben mussten: „Wir haben das Ziel in diesem Quartal verfehlt, weil ein Upgrade an diesem riesigen internen System schiefgelaufen ist.“

[Scott Robohn] (44:29 – 44:31)

Das ist noch gar nicht so lange her.

[Andrew Wertkin] (44:31 – 45:58)

Ja, das ist noch gar nicht so lange her. Ja. Und das war sozusagen die gesamte anfängliche Salesforce-Marketingkampagne mit dem Slogan „No Software“. Und wir haben das für euch umgesetzt und all diese großartigen Aspekte rund um, äh, SaaS, ähm, äh, in dieser Welt – wie die Disruption begann: All diese neuen Unternehmen brachten benutzerfreundliche SaaS-basierte Systeme auf den Markt. Sie sind zwar immer noch das Hauptsystem, aber es gibt diese neuen Systeme für die Personalabteilung, für das Reisemanagement, für den Einkauf, für was auch immer – für jeden Teil dieses Systems. Und dann haben diese großen Unternehmen in diesem Bereich natürlich einfach diese Firmen eine nach der anderen, nach der anderen, nach der anderen aufgekauft. Und in gewisser Weise bin ich mir, abgesehen davon, nicht ganz sicher, ob es überhaupt noch zu Übernahmen kommen wird – es könnte einfach viel zu viel geben, was man übernehmen könnte.

Ähm, ihr werdet viele Unternehmen sehen, die, ähm, „System of Engagement“-Konzepte entwickeln – so etwas wie Wertversprechen für bestehende Plattformen –, um nach und nach das Nutzer- oder System-Engagement, äh, zu übernehmen. Und, ähm, und das wird viel schneller passieren als, als, äh, das Reisemanagement und, und, äh, na ja, Ziele im Personalwesen oder im Einkauf oder was auch immer diese System-Engagements waren, die damit angefangen haben, dies mit einem großen internen System umzusetzen. In dieser 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 –, denke ich, dass uns das gewissermaßen wieder zu den „Best-of-Breed“-Lösungen zurücktreiben wird.

[John Burke] (45:59 – 46:42)

Und ich kann mir sogar vorstellen, diesen Weg noch sehr weit 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, ob sie die Hälfte dessen, was im Funktionsbereich X zu tun ist, besser, schneller und kostengünstiger erledigen können. Jetzt habe ich also zwei Lösungen in diesem Bereich, und es ist die KI, die verwaltet, welche Arbeit an welche Lösung geht. Und, weißt du, es ist so eine Art „Redundant Array of Software Vendors“-Ansatz. Äh, ich werde einfach dort arbitrieren, wo es am besten zu den Kriterien passt, die meine KI für mich als am wichtigsten erkennt – Zeit sparen, Geld sparen, bessere Leistung, was auch immer. Ja. Ja.

[Andrew Wertkin] (46:43 – 50:10)

Ja. Denn ich sehe ja, wenn man heutzutage auf eine Tech-Messe geht, besonders im Bereich Netzwerke, aber, ähm, weißt du, so ziemlich in jedem, jedem technikbezogenen Bereich. Und man sieht ein Unternehmen nach dem anderen, das seine KI-Plattform verkauft – egal, woher sie kommen, sie haben jetzt eine KI-Plattform, die herstellerunabhängig ist. Warum auch nicht? Jeder hat MCP-Server. Und was hat man dann als Unternehmen: mehrere Plattformen für agentenbasierte Abläufe oder eine einzige Plattform – also einen Meta-Agenten, der eine Reihe anderer Agentenplattformen verwaltet. Was, wenn ich hier die falsche einsetze? Und, äh, und, und wie schnell kann ich das ändern? Und, äh, ähm, und, und anscheinend – ich verstehe diesen Teil nicht, weil ich so nicht arbeite –, aber die Leute neigen eben auch zu einer Vorliebe für das Vertraute.

Oh. Oh ja. Sie sagten, sie könnten das alles für mich übernehmen. Also glaube ich das einfach mal, weißt du? Und, äh, und es läuft auf dieses Thema hinaus. Es ist lustig, weißt du, vorhin habe ich gesagt, ich habe ein echtes Beispiel genannt. Ich hatte noch nie ein EBPF geschrieben, so einen, äh, du weißt schon, äh, internen, Hochgeschwindigkeits-Logger. Und, äh, und jetzt habe ich es versucht, ich könnte immer noch keines schreiben. Ähm, genau.

Ich nutze das als Experiment: Was passiert, wenn ich diesen Prozess in einem Bereich anwende, in dem ich zwar genau weiß, wie das Ganze funktioniert, aber noch nie tatsächlich Software geschrieben habe? Was werde ich lernen? Ich habe gelernt, wie schnell ich etwas umsetzen kann, von dem ich vorher keine Ahnung hatte. Ähm, und allein dadurch, dass ich die Dinge festgelegt habe, über die wir zuvor gesprochen haben – also Kriterien, Abbruchkriterien und Dinge, die mir wichtig sind, die 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ß nicht, ob … äh … weißt du, ich weiß nur, dass es wartbarer Code ist, der funktioniert.

Ich meine, weißt du, ich weiß noch mehr als das. Das ist wirklich gut dokumentiert. Also, ich denke, mein Punkt ist, ähm, äh, dass die Leute das Zeug immer noch lernen müssen, weißt du, um diese Erfahrung sozusagen weiterzugeben. Und das, ich meine, so sehr ich diese Technologie auch schätze, ist meine größte Angst einfach, ähm, dass die schlimmsten Fehler immer dann entstehen, wenn jemand glaubt, er habe Recht. Und die Leute sind entweder zu eingeschüchtert oder zu sehr von jemandem beeindruckt oder zu seltsam oder einfach zu faul, um jemanden zu hinterfragen, der ganz sicher weiß, wie man etwas erledigt. Und das Endergebnis sind Dinge, die hätten verhindert werden können und die, ähm, Probleme verursachen. Und wir sehen das sozusagen überall, weißt du, von der Technik über, äh, soziale Umgebungen bis hin zu allen anderen Bereichen, weißt du, und, äh, Gruppendenken oder, aber, aber, weißt du, es ist, ähm, genau das, wofür ich mich auf meine Experten verlasse, äh, weißt du, selbst wenn sie es nicht wissen, selbst wenn es richtig klingt. Je richtiger es für sie klingt, desto unwahrscheinlicher ist es, dass sie es für bare Münze nehmen, äh, denn da muss doch etwas daran falsch sein. Was ist es? Es ist ein Rätsel. Das sind, weißt du, in vielen Fällen Ingenieure. Und, und, ähm, ähm, so sehr ich die Technologie auch schätze, sie nutze und vorantreibe, zum Beispiel, um mit ihr Mehrwert zu schaffen, äh, gibt es doch einen Teil davon, der mir einfach Unbehagen bereitet.

[John Burke] (50:12 – 50:35)

Äh, ein durchaus warnender Hinweis, mit dem wir das Gespräch beenden können. Ja. Vielen Dank, Andrew, dass du heute bei uns warst. Das war unglaublich interessant und bietet Unternehmensstrategen viel Stoff zum Nachdenken, wenn sie darüber nachdenken, wie es weitergeht, äh, in ihren IT-Abteilungen. Äh, Scott, vielen Dank auch an dich, dass du heute bei uns warst. Und wie immer vielen Dank an alle Zuschauer.