Können LLMs wirklich programmieren?
Die kurze Antwort: Ja und Nein. LLMs können Code generieren, der beeindruckend aussieht. Sie erstellen Java-Klassen, implementieren Design Patterns und instanziieren Algorithmen. Das Problem beginnt beim genaueren Hinsehen.
Ein LLM ist ein statistisches Modell, das gelernt hat, welche Token-Sequenzen wahrscheinlich aufeinander folgen. Es „versteht“ Code nicht semantisch – es hat lediglich gelernt, welche Muster häufig vorkommen. Das ist, wie akzentfrei Chinesisch zu sprechen, ohne ein Wort zu verstehen. Und dennoch funktioniert diese Annäherung erstaunlich gut. Zu gut, um sie zu ignorieren, aber nicht gut genug, um ihr blind zu vertrauen.
Die Demokratisierung – oder doch nicht?
Enthusiasten verkünden, LLMs würden die Programmierung demokratisieren. Diese Vision erinnert an 4GL-Sprachen oder No-Code-Plattformen. Tatsächlich kann ein Neuling heute ein Spring-Boot-Projekt aufsetzen, ohne Dependency Injection zu verstehen. Aber um den Code zu debuggen, zu warten und zu erweitern, braucht der Entwickler weiterhin fundamentales Wissen.
Die Demokratisierung findet anders statt: LLMs machen erfahrene Entwickler produktiver, während sie Anfängern gefährliche Illusionen von Kompetenz vermitteln.
Java im KI-Zeitalter
Java hat eine besondere Stellung. Frameworks wie LangChain4j und Spring AI zeigen, wie sich Generative AI in Enterprise-Architekturen integrieren lässt. Java glänzt dabei durch Typsicherheit, explizite Interfaces und eine Kultur der Robustheit.
Ein LLM mag halluzinieren. Ein gut strukturiertes Java-System mit klaren Schnittstellen, Tests und Fehlerbehandlung sowie intelligentes Prompt Engineering können diese Halluzinationen abfangen und kontrollieren.
Drei Kategorien der Integration
Wir sollten dabei die Kategorien der Integration beachten:
- In der assistenzbasierten Integration fungieren LLMs als intelligente Autocomplete-Werkzeuge wie GitHub Copilot. Das macht sie relativ risikoarm.
- Bei eingebetteter KI-Funktionalität dienen LLMs als Systemkomponenten, etwa als Chatbots oder zur Dokumentenanalyse. Die Herausforderungen heißen hierbei Prompt Injection, Halluzinationen, Kostenkontrolle.
- Im Zuge von autonomen Agenten orchestrieren LLMs Workflows und treffen Entscheidungen. Die entscheidende Frage lautet in diesem Kontext: Wie viel Autonomie wollen wir abgeben?
Halluzination: Feature oder Bug?
Die Neigung von LLMs zur Halluzination ist faszinierend. Ist dies nicht genau das, was Kreativität ausmacht? Bei innovativen Architekturen wollen wir, dass das System über Bekanntes hinausdenkt. Im Brainstorming ist Halluzination wertvoll. Bei Diagnosen oder Transaktionen katastrophal.
Die Lösung liegt in der Architektur: LLMs in kontrollierten Sandboxen können Ausgaben validieren und kritische Entscheidungen absichern.
Der Elephant Code
LLMs generieren vollständige Lösungen, selbst wenn minimale genügen. Codebasen schwellen an, die Wartbarkeit sinkt. Die Lösung lautet: präzise Prompts und kritisches Review.
Die Zukunft kombiniert menschliche Kreativität mit KI-Geschwindigkeit. Ein Architekt skizziert, ein LLM generiert Vorschläge, Tests verifizieren, der Architekt verfeinert. Keine dystopische Zukunft überflüssiger Entwickler, sondern eine, in der wir uns auf interessante Probleme konzentrieren.
Hier stellen sich sofort ethische Fragen. Wer ist verantwortlich bei Fehlern? Wie gehen wir mit Urheberrecht um? Wie verhindern wir Vorurteile? Die Java-Community ist gut positioniert, um hier Standards zu setzen.
Persönliches Fazit
LLMs verändern unser Handwerk fundamental. Manche Aspekte gehen verloren, aber neue Möglichkeiten entstehen: etwa in größeren Abstraktionen zu denken, schneller zu experimentieren. Ich habe gelernt, LLMs als das zu sehen, was sie sind: brillante Assistenten, aber schlechte Entscheider. Sie können inspirieren, aber nicht führen.
Generative AI ist das nächste Kapitel einer fortlaufenden Geschichte. Die Softwareentwicklung mag sich verändern, aber nicht verschwinden. Denn am Ende geht es nicht um die Werkzeuge, sondern um die Probleme, die wir lösen, und die Werte, die wir hochhalten. Das ist eine Invariante.
In diesem Sinne wünsche ich Ihnen viel Spaß mit der neuen Ausgabe von JavaSPEKTRUM 1/26.
Ihr Prof. Dr. Michael Stal
