Der Gründer von Spring kehrt an die Front zurück, um an einem KI-Framework zu arbeiten – und sagt: „Das ist die letzte Generation von Frameworks, die Menschen noch selbst auswählen werden.“

Rod Johnson ist wieder an der Frontlinie.

Er ist der Schöpfer von Spring und hat einst fast die Art und Weise neu definiert, wie Unternehmens-Java-Anwendungen geschrieben werden sollten. Mehr als zwei Jahrzehnte später gründet er erneut ein Unternehmen und entwickelt ein Open-Source-Framework namens Embabel für Unternehmens-AI-Agenten. Er versucht, Large Language Models (LLMs) in reale Geschäftssysteme zu integrieren, damit sie nicht nur Werkzeuge aufrufen können, sondern in kontrollierbaren, nachvollziehbaren und auditierbaren Prozessen arbeiten.

Interessanterweise arbeitet er diesmal wieder an einem Framework, aber er ist nicht optimistisch in Bezug auf die Zukunft von "Frameworks", zumindest nicht in der gleichen Weise wie früher. Nach seiner Meinung werden die Modelle weiterhin stärker werden, und die Werkzeuge werden immer mehr Entscheidungen für die Entwickler treffen. Wird Embabel von stärkeren Modellen eingeholt? Brauchen Unternehmen noch eine solche "Harness-Schicht"? Wird das zukünftige Framework von den Entwicklern ausgewählt oder von AI-Werkzeugen automatisch bestimmt? Diese Fragen drehen sich um das, was er in einem Interview gesagt hat: Dies könnte die letzte Welle von Frameworks sein, die von Menschen persönlich ausgewählt werden.

Wenn diese Aussage von jemand anderem gemacht würde, könnte sie einfach eine übertriebene Einschätzung der AI-Zeit sein. Aber wenn sie aus dem Mund des Gründers von Spring kommt, hat sie eine andere Bedeutung. Denn Rod Johnson war selbst an der Entstehung der Framework-Ära beteiligt und hat gesehen, wie ein Framework zur Infrastruktur der Unternehmens-Softwareentwicklung wird. Jetzt kehrt er auf das Schlachtfeld zurück, aber er meint, dass die Entscheidungsgewalt sich verschiebt: Entwickler werden möglicherweise nicht verschwinden, aber die Zeit, in der Entwickler persönlich Frameworks auswählen, Technologie-Stacks aufbauen und die Systemstruktur bestimmen, könnte ihrem Ende entgegengehen.

Dieser Artikel basiert auf einem Podcast-Video und wurde von InfoQ bearbeitet.

Die Kernaussagen sind wie folgt:

• Wenn ich TensorFlow zur Modelltraining, -feinabstimmung, Datenverarbeitung und -aufnahme verwenden möchte, werde ich natürlich Python nutzen. Aber die Ermächtigung der Anwendungs-Schicht von Generative AI eignet sich besser, in der ursprünglichen Programmiersprache der Anwendung durchgeführt zu werden. Wenn die Anwendung in Java geschrieben ist, dann sollte es in Java erfolgen.
• Sobald Sie in komplexe Anwendungen eindringen, werden Sie schnell in ein Durcheinander geraten, wenn Sie die architektonische Kontrolle nicht aufrechterhalten. Ihr Agent wird gerne neue Funktionen hinzufügen, aber mit jeder neuen Funktion verschlechtert sich das Design, und der Code wird sehr schlecht.
• Entwickler sollten nicht viel Zeit mit dem Schreiben von Code verbringen, denn Sie können durch die Konzentration auf Ihre einzigartigen Stärken mehr Nutzen ziehen.
• Jeder Entwickler sollte grundsätzlich alle ein bis zwei Jahre eine neue Programmiersprache lernen, denn es verändert wirklich Ihre Denkweise.
• Dies könnte bereits die "letzte Generation von Frameworks sein, die von Menschen aktiv ausgewählt werden". In Zukunft werden immer mehr Technologieauswahlen von unseren Werkzeugen für uns getroffen.

Der Gründer von Spring kehrt zur Unternehmensgründung an der Frontlinie zurück

Simon: Als ich Ihre Laufbahn studierte, stellte ich fest, dass Sie vor der Gründung von Spring einen Doktortitel über die Klaviermusik aus dem 19. Jahrhundert in Paris hatten.

Rod: Ja, mein erster Abschluss war ein Doppelstudium in Musik und Informatik. Ich konnte damals überhaupt nicht entscheiden, in welche Richtung ich gehen sollte. Später bekam ich ein Forschungsstipendium in Australien, um einen Musikdoktor zu machen, und habe zwei Jahre Musikgeschichte am Sydney Conservatorium unterrichtet. Doch der Drang, Code zu schreiben, hat nie aufgehört. Mitte der 90er Jahre habe ich auch Shareware geschrieben, und tatsächlich haben Leute mir Schecks geschickt.

Später wurde mir klar, dass ich in der Musik-Akademie wahrscheinlich nie in Sydney eine eigene Wohnung kaufen würde. Also traf ich eine Entscheidung: Eines dieser Dinge sollte mein Hobby, das andere meine Berufung sein - und ich hatte damals genau das Gegenteil getan. Aber in den nächsten zehn Jahren habe ich fast nie Klavier gespielt, weil meine Karriere einfach zu anstrengend war.

Simon: Also war dies kein seltsamer Umweg oder so etwas, sondern einfach, dass Sie sehr kreativ sind und sowohl das Schreiben von Code als auch die Musik genießen.

Rod: Seit ich Mitte der 80er Jahre das erste Mal Code geschrieben habe, habe ich fast nie aufgehört zu programmieren, weil ich es einfach liebe. Selbst wenn heute der größte Teil des Codes von einem AI-Coding-Agenten geschrieben wird, spüre ich immer noch die gleiche Aufregung, weil ich die Kontrolle noch in der Hand habe und immer noch Dinge erschaffe und gestalte. Selbst wenn ich nicht mehr jede Zeile selbst tippe, ist es für mich genauso befriedigend, solange das Ergebnis das gleiche ist.

Simon: Nach der Übernahme von SpringSource haben Sie viele Jahre in Boards und Investitionen gearbeitet und dann Embabel gegründet. Was hat Sie dazu gebracht, zu denken: "Jetzt ist der richtige Zeitpunkt"?

Rod: Ich denke, es liegt daran, dass die Branche an einem großen Wendepunkt steht. Als GPT-3 und später ChatGPT plötzlich wirklich praktisch wurden und nicht mehr sich selbst wiederholten oder in seltsame Sackgassen gerieten, habe ich sofort erkannt, dass es schwierig ist, diese Technologie wirklich zur Lösung von Unternehmensproblemen zu nutzen. Tatsächlich habe ich zwei Jahre vor diesem Zeitpunkt aus persönlichem Interesse schon viel TensorFlow-Code geschrieben und mich viel mit der unterliegenden AI-Technologie beschäftigt. Dies hat sich natürlich in die Idee entwickelt, ein Framework zu schaffen, um diese Probleme zu lösen.

Simon: In Bezug auf Unternehmen werden viele Teams jetzt aufgefordert, Java beiseite zu legen und alles in Python neu zu schreiben. Sie haben öffentlich gesagt, dass dies falsch ist und sogar gesagt: "Dies ist das letzte Jahr, in dem Python in der AI-Branche dominiert". Warum?

Rod: Wenn Sie ein Geschäftsproblem lösen möchten, müssen Sie die "Adjazenz" dieses Problems berücksichtigen. Mit was arbeiten Sie? Wahrscheinlich mit Datenbanken, Unternehmensdiensten und bestehenden Code-Bibliotheken. Gleichzeitig müssen Sie auch etwas Neues behandeln: das LLM. Aber das LLM läuft nicht in Ihrem Python-Prozess - bis zum Ende des Universums wird Python nicht in der Lage sein, Inference selbst auszuführen. Das LLM ist einfach ein sehr einfacher HTTP-Aufruf. Deshalb frage ich mich immer, warum Menschen glauben, dass eine bestimmte Programmiersprache einen natürlichen Vorteil bei der Ausführung eines so einfachen HTTP-Aufrufs hat.

Tatsächlich beginnen die Leute allmählich, dies zu verstehen. OpenClaw ist nicht in Python geschrieben. Peter Steinberger hat die Sprache verwendet, die er bevorzugt. Für viele Unternehmensanwendungen ist es offensichtlich, dass sie in Java geschrieben sind. Die entscheidende Adjazenz liegt in der bestehenden Geschäftslogik und den bestehenden Unternehmensdiensten. Die richtige Vorgehensweise ist also offensichtlich, einen einfachen HTTP-Aufruf aus Ihrem Java-Stack heraus abzusetzen.

Ich denke, dass der grundlegende Grund für diese Verwirrung darin besteht, dass die Leute "Data Science" und "Unternehmens-AI-Anwendungen" nicht unterscheiden. Es sind zwei völlig verschiedene Dinge. Vor Embabel habe ich viel Python geschrieben. Vor zwei Jahren war ich in Python sogar flüssiger als in Java. Wenn ich TensorFlow zur Modelltraining, -feinabstimmung, Datenverarbeitung und -aufnahme verwenden möchte, werde ich natürlich Python nutzen. Aber die Ermächtigung der Anwendungs-Schicht von Generative AI eignet sich besser, in der ursprünglichen Programmiersprache der Anwendung durchgeführt zu werden. Wenn die Anwendung in Java geschrieben ist, dann sollte es in Java erfolgen.

Simon: Embabel ist in Kotlin geschrieben, richtig?

Rod: Der Kern von Embabel ist fast vollständig in Kotlin geschrieben. Aber die meisten unserer Beispiele sind in Java. Wir haben viel Zeit und Mühe darauf verwendet, sicherzustellen, dass es für Java-Nutzer völlig nahtlos funktioniert - wie Sie erwarten würden, verwenden die meisten unserer Nutzer Java. Sie werden keine Companion-Objekte, keine `.kt`-Dateien und keine anderen seltsamen Dinge sehen. Es sieht wie sehr eleganten und flüssigen Java aus. Also arbeite ich, wenn ich am Kernframework arbeite, in Kotlin, und wenn ich an Beispielanwendungen arbeite, in Java. Ehrlich gesagt, ist die Java-stilige API sehr gut. Selbst wenn Sie das Framework in Kotlin verwenden, ist die Erfahrung ähnlich wie in anderen Sprachen.

Simon: Und die Integration zwischen den beiden Sprachen ist sowieso nahtlos. Sie können direkt von Kotlin zu Java wechseln.

Rod: Vor etwa dreizehn Jahren habe ich viel Scala verwendet. Ich mag die Sprache Scala sehr gerne, aber die Integration mit Java war schmerzlich. Jedes Mal, wenn Sie mit einer Sammlung arbeiten, war es eine Qual. Die Schöpfer von Kotlin haben es dagegen sehr gut gemacht, die Java-Interoperabilität zu gewährleisten. Sie haben nicht die Probleme eingeführt, die Scala hatte, wie z. B. zerstörerische Änderungen und fehlende binäre Kompatibilität. Also, ja, ich finde, dass Kotlin eine sehr gut nutzbare Sprache ist.

Ich denke auch, dass es wichtig ist, darauf hinzuweisen, dass Java sich sehr verbessert hat. Ich finde es ärgerlich, dass viele Leute Java gerne als Strohmann angreifen. Viele Leute tun so, als hätte Java sich nicht entwickelt, aber Java hat sich tatsächlich sehr entwickelt.

Coding-Agenten zerstören Ihre Code-Bibliothek

Simon: Sie haben erwähnt, dass AI im Wesentlichen als eine getrennte Schicht in bestehende Systeme hineingepresst wird, anstatt tiefer integriert zu werden, was zu einigen Misserfolgsfällen geführt hat. Wie sehen Sie die echten Misserfolgsfälle von Unternehmens-AI aus?

Rod: Ich denke, das größte Problem besteht darin, dass Teams, wenn die oberste Leitung den Befehl "Alles mit AI" erteilt, AI-Projekte starten, ohne einen echten Geschäftsfall zu haben und ohne zu prüfen, ob AI überhaupt geeignet ist. Ein Haupt-Antipattern ist die Idee: "Wir müssen mehr AI verwenden", ohne jemals zu fragen: Warum? Wofür? Obwohl ich AI sehr liebe und fasziniert bin, sollten Sie, wenn Sie eine Aufgabe ohne LLM erledigen können, natürlich kein LLM verwenden. Es ist billiger, sicherer und schneller.

Also sollten Organisationen zuerst darüber nachdenken, "wie wir von hier dorthin kommen". Nehmen wir als Beispiel einen Kunden in Australien. Sie haben zunächst eine kleine Problemklasse identifiziert: Auf ihrer Website gibt es ein bestimmtes Formular, das von den Kunden ausgefüllt werden muss, bevor es manuell überprüft werden kann. In 95 % der Fälle ist es eigentlich sehr einfach, obwohl es mit regulären Ausdrücken etwas mühsam ist. Also haben sie diesen Reibungspunkt beseitigt und in 95 % der Fälle die Kunden sofort weitergeleitet, ohne dass sie auf die manuelle Bearbeitung warten mussten. Ich finde, dass dies ein ausgezeichneter Startfall ist: Zuerst kleine Ergebnisse erzielen und allmählich Vertrauen aufbauen.

Außerdem verursacht das Problem des "Alien-Stacks" Schäden in zwei Richtungen. Erstens macht es alles technisch schwieriger. Zweitens gibt es die Strategiegewalt oft in die falschen Hände - Leute, die überhaupt nicht mit dem Kerngeschäft vertraut sind und möglicherweise nie eine Kerngeschäftsanwendung gesehen haben, leiten die Strategie. Wenn Sie diese Anwendungen ermächtigen möchten, funktioniert dieser Weg überhaupt nicht.

Letztes Jahr habe ich mit dem Chef-AI-Architekten eines großen australischen Unternehmens gesprochen. Er war ein Python-Entwickler. Er hat höflich zu meiner Präsentation zugehört, aber nicht wirklich interessiert gewesen. Am Ende des Gesprächs hat er versucht, freundlich zu sein und gesagt: "Ich bin sicher, dass es irgendwo in unserem Unternehmen Java gibt. Ich werde mal nachfragen." Ich habe nie in diesem Unternehmen gearbeitet, aber als Fachmann weiß ich genau, dass etwa 70 % des Codes in Java geschrieben sind und der Rest in .NET, und sie .NET allmählich abschaffen. Dieser Mann war fast ein Jahr im Unternehmen, aber er hat nie gefragt: "Übrigens, in welcher Sprache ist unsere Software geschrieben?" Für ihn scheint es überhaupt nicht wichtig zu sein.

Simon: Es gibt ein immer häufigeres Phänomen: Wir als Entwickler haben einen großen Abstand zu der tatsächlichen Code-Implementierung. Wir vertrauen AI zu sehr oder übertragen zu viele Entscheidungen an sie und überlassen zu viel an AI. Viele Kenntnisse liegen tatsächlich bei der AI, und wir werden von der Abstraktion entfernt. Wie gravierend halten Sie dieses Problem für?

Rod: Ich denke, dass eine Kernkompetenz für Entwickler darin besteht, auf diese neue Weise zu arbeiten und gleichzeitig die wirklich wichtigen Kontrollpunkte zu behalten. Es ist tatsächlich möglich, mit Vibe Coding einige Dinge zu tun, wie z. B. bestimmte Arten von UI-Anwendungen, die sowieso nur einmalig verwendet werden. Agenten sind in diesem Bereich sehr, sehr gut. Aber Sie können nicht mit Vibe Coding ernsthafte Software schreiben.

Ich bin ein aktiver Nutzer von Coding-Agenten. Ich schreibe vielleicht maximal 5 % des Codes, vielleicht sogar weniger, aber ich halte die Kontrolle fest in der Hand. Ich habe festgestellt, dass Agenten von der Design-Perspektive aus öfter falsch liegen als richtig.

Wir müssen immer noch das Verständnis für die Architektur haben, wissen, was passiert, und nicht zu sehr vertrauen. Denn sobald Sie in komplexe Anwendungen eindringen, werden Sie schnell in ein Durcheinander geraten, wenn Sie die architektonische Kontrolle nicht aufrechterhalten. Ihr Agent wird gerne neue Funktionen hinzufügen, aber mit jeder neuen Funktion verschlechtert sich das Design, und der Code wird sehr schlecht.

Simon: Sie haben erwähnt, dass Sie nur 5 % des Codes schreiben und der Rest von AI generiert wird. Tun Sie dies absichtlich? Ist es, weil Sie nicht mehr schreiben möchten, um mehr Kontrolle über das Ergebnis zu haben?

Rod: In Open-Source-Projekten schreibe ich einen höheren Anteil selbst und bin möglicherweise konservativer. Aber in einigen unserer internen Anwendungen beträgt der Anteil der von AI generierten Code fast 95 %. Wenn Sie diesen Code lesen, würden Sie denken, dass ich ihn geschrieben habe. Der Designstil ist sehr klar. Ich sitze da und schaue mir die Unterschiede an, das Output, und stoppe oft, um es zu korrigieren: "Nein, Sie haben dies hart kodiert. Hier sollte es eine Strategie geben und herausgearbeitet werden."

Ich glaube, dass dieses Modell möglicherweise bessere Ergebnisse erzielen kann als reines manuelles Schreiben oder reines Schreiben durch einen Coding-Agenten. Ich schreibe mit einem Coding-Agenten viel schneller und die Qualität ist auch besser. Aber wenn ich alles vollständig an einen Coding-Agenten überlasse, bin ich überzeugt, dass die Qualität stark sinken wird und am Ende auch die Geschwindigkeit.

Das Herzstück von Embabel: Ein Planungsalgorithmus aus dem Bereich von Spiel-NPCs

Simon: Lassen Sie uns über die Kernkomponente "Planner" in Embabel sprechen. Dies ist ein Suchalgorithmus namens GOAP (Goal-Oriented-Action-Planning), der ursprünglich für NPCs in Spielen entwickelt wurde, richtig? Der Schlüsselpunkt ist, dass er deterministisch ist. Andere Frameworks wie LangChain und Crew.ai lassen dagegen eher das LLM entscheiden, was als nächstes zu tun ist und wie die Planung erfolgen soll. Warum haben Sie diesen Algorithmus aus dem Bereich von Spiel-NPCs ausgewählt?

Rod: Zunächst habe ich tatsächlich die offensichtlichste Methode in Betracht gezogen - die Zustandsmaschine. Um ehrlich zu sein, ist LangGraph deterministisch. Sie definieren die Zustandsmaschine im Voraus. Also habe ich auch eine Zeit lang diese Methode verwendet. Aber lassen Sie uns einen Schritt zurückgehen und über die Gründe für die Planung sprechen.

Naturgemäß können Sie einfach eine Reihe von Werkzeugen an das Modell