Was Code-LLMs für die Zukunft der Softwareentwicklung bedeuten

Wir sind in ein Zeitalter eingetreten, in dem Code gemeinsam mit Maschinen geschrieben wird.

Als OpenAI's ChatGPT zum ersten Mal in der Tech-Szene auftauchte, läutete es das Zeitalter der generativen KI ein, wobei die Codegenerierung einer der ersten Anwendungsfälle war. Darauf folgten Programmierassistenten mit künstlicher Intelligenz (KI), vom Pionier GitHub Copilot bis hin zu Anbietern wie Amazon Q Developer, Anthropics Claude Code, Googles Gemini Code Assist, IBM Bob und Mistral Code.

Doch unter diesen Codierungs-Tool verbirgt sich eine mächtige Technologie: große Sprachmodelle (LLMs) für Code. Und sie verändern die Art und Weise, wie Software entwickelt wird.

Wir haben mit einigen IBM-Experten gesprochen, um Insiderinformationen darüber zu erhalten, wie Code-LLMs die Rolle des Softwareentwicklers neu definieren und welche Prognosen sie für die Zukunft dieser Modelle haben. Folgende Personen teilen ihre Erkenntnisse:

• Kaoutar El Maghraoui, Principal Research Scientist

• Bridget McGinn, Research Software Engineer, AI for Code

• Rameswar Panda, Distinguished Engineer

• Fumiko Satoh, Senior Technical Staff Member and Senior Manager, AI for Code and Security

Code-LLMs sind spezialisierte Modelle, die auf Quellcode trainiert wurden. Sie können entweder von Grund auf neu erstellt werden oder auf der Grundlage eines vorab trainierten Modells auf die Codierung von Datensätzen feinabgestimmt werden. Diese Trainingsdaten müssen von hoher Qualität und vielfältig genug sein, um sicherzustellen, dass Code-LLMs verschiedene Codierungsszenarien in verschiedenen Programmiersprachen bewältigen können.

Da LLMs für Code typischerweise von KI-Modellen abgeleitet sind, die für die natürliche Sprachverarbeitung (NLP) entwickelt wurden, nehmen sie oft natürliche Sprachbeschreibungen als Prompts. Sie sind in der Lage, diese realen Codierungsaufgaben zu bewältigen:

• Unterstützung beim Debuggen

• Codevervollständigung (auch bekannt als Autovervollständigung)

• Codegenerierung

• Code-Refactoring

• Code-Zusammenfassung

• Erstellung von Dokumentation (als Inline-Kommentare für Code-Snippets)

• Modernisierung von Altlast-Code (wie die Konvertierung von COBOL in Java)

• Vorschläge zur Codeoptimierung

• Übersetzung von bestehendem Code von einer Programmiersprache in eine andere (z. B. von Python nach JavaScript)

Zu den populären Beispielen für Code-LLMs gehören Googles CodeGemma, Metas Code Llama sowie Mistrals Codestral und Devstral. Zu den Open-Source-Code-Modellen gehören unterdessen DeepSeek Coder, IBM Granite Code und Qwen3 Coder.

Zu den anderen LLM-Programmen, die nicht ausschließlich auf Codierung ausgerichtet sind, aber für die Codierung optimiert wurden, gehören Claude Sonnet und Opus von Anthropic sowie Gemini Pro von Google.

Code-LLMs demokratisieren den Zugang zur Softwareentwicklung und unterstützen Laienprogrammierer, Fachexperten und andere nicht-professionelle Entwickler, die keine formelle Ausbildung oder Schulung im Bereich Informatik haben. Sie ermöglichen schnelles Prototyping, kürzere Iterationszyklen und eine schnellere Einarbeitung neuer Softwareentwickler.

Über die Umgestaltung der Softwareentwicklung hinaus definieren Code-LLMs die Rolle von Softwareentwicklern neu.

Laut El Maghraoui entwickeln sich Softwareingenieure von Codeproduzenten zu Codekuratoren. „Obwohl die Codierung weiterhin essenziell ist, verlagert sich der Schwerpunkt auf Prompt Engineering. Wie formulieren wir die richtigen Fragestellungen im Kontext dieser LLMs? Und anstatt jede einzelne Codezeile zu schreiben, orchestrieren Entwickler zunehmend KI-generierten Code und fügen die Teile zusammen.“

Diese Entwicklung ist jedoch nur die Spitze des Eisbergs. El Maghraoui glaubt, dass sich die Entwicklerrollen zu einem „absichtsorientierten Engineering“ weiterentwickeln werden. Die Idee ist, von der Syntax wegzukommen und sich auf die Struktur zu konzentrieren, die feineren Details zu belassen und das Gesamtbild zu betrachten sowie vom Was zum Warum zu wechseln und Ziele, Ergebnisse und Auswirkungen hervorzuheben.

Laut McGinn können Code-LLMs als in ein Programm importierte Bibliotheken behandelt werden. „Probleme können schneller gelöst werden, genauso wie Bibliotheken uns als Ingenieuren helfen, Funktionen zu nutzen, die bereits vorhanden sind, und das Rad nicht neu erfinden zu müssen.“

Diese Sichtweise stimmt mit generativem Rechnen überein. In diesem Framework wird ein Codemodell als modulare Softwarekomponente in Systeme integriert und wie eine programmierbare Schnittstelle behandelt. Dadurch können Aufgaben auf niedriger Ebene abstrahiert werden, sodass sich die Entwickler verstärkt auf die Lösung übergeordneter Probleme konzentrieren können.

„Sie müssen Design Thinking in Betracht ziehen, anstatt Code zu schreiben“, sagt Satoh. „Wir brauchen hochqualifizierte Ingenieure, die die Architektur eines Systems entwerfen können.“

Es ist eine Rolle, die immer multidisziplinärer wird und nicht nur Design und Architektur, sondern auch andere Dimensionen wie Ethik und Sicherheit umfasst. „Es ist weniger manuell und es gibt mehr Automatisierung, aber es ist strategischer“, sagt El Maghraoui. „Sie verbinden Softwareentwicklung mit systemischem Denken, Produktdenken und ethischer Argumentation. Wir beherrschen nun nicht nur Codierung, sondern entwickeln uns zu KI-kompetenten und KI-zentrierten Ingenieuren.“

Dies eröffnet Möglichkeiten zur Weiterbildung bei höherwertigen Aufgaben, insbesondere für Junior-Entwickler. „Viele Benchmarks zielen darauf ab, die Funktionalität eines Junior-Entwicklers abzubilden. Wenn das also eine Metrik ist, die wir anstreben, dann besteht die Idee darin, dass wir sie nicht mehr so dringend benötigen“, sagt McGinn. „Wir brauchen Leute, die ein tieferes Niveau als ein Junior-Entwickler haben, oder sie müssen vielleicht nicht mehr die Rolle des Junior-Entwicklers durchgemacht haben, um zu verstehen, was ein Senior-Entwickler tut.“

Panda merkt an, dass Code-LLMs, wie jedes große Sprachmodell, ihre Nachteile haben. Er rät zur Vorsicht, wenn es um Urheberrecht, Verzerrung und Sicherheit geht, insbesondere bei der Arbeit an wichtigen Anwendungen in Sektoren wie dem Finanzwesen und dem Gesundheitswesen.

„Sie können sich nicht einfach blind auf sie verlassen“, sagt Panda. „Sie müssen ihren generierten Code immer mit Vorsicht genießen.“

Dieser Skeptizismus muss auch mit Leistungsoptimierungsmechanismen und Validierungsmaßnahmen kombiniert werden, um Solidität und Genauigkeit zu überprüfen. „Man sollte trotzdem unbedingt Testfälle schreiben und den Code genauso gründlich überprüfen, wie man es bei manuell geschriebenem Code tun würde“, sagt McGinnis.

El Maghraoui betont die Unterstützung durch Code-LLMs statt der Abhängigkeit von ihnen. „Wenn wir sie als Lehrmittel, als Partnerprogrammierer oder als Ideengenerator einsetzen, können sie unser Lernen, unsere Kreativität und unsere Produktivität steigern. Doch wenn wir sie als Krücke benutzen – ohne Selbstreflexion, ohne Überprüfung –, können sie unser Urteilsvermögen und unsere Verantwortlichkeit untergraben.“

Validierung ist nur möglich, wenn Entwickler die zugrunde liegenden Rechenprinzipien verstehen. Denn wie kann man die Gültigkeit des von diesen Modellen generierten Codes überprüfen, wenn man die Grundlagen der Programmierung nicht versteht?

„Es ist zwar schnelles Codieren, aber nicht immer robust, korrekt oder sicher“, sagt El Maghraoui. Sie fügt hinzu, dass die Verwendung des generierten Codes in seiner jetzigen Form gefährlich sein kann. „Das kann zu Fragilität in den Codebasen führen. Wenn Sie sich zu sehr auf diese Modelle verlassen oder ihren Ausgaben zu sehr vertrauen, kann dies zu subtilen Fehlern oder Ineffizienzen führen, insbesondere in kritischen Systemen. Deshalb ist es wichtig zu verstehen, was passiert.“

Hier kommt fundiertes Fachwissen ins Spiel, das durch grundlegende Softwareentwicklungskonzepte ermöglicht wird.

„In den Schulen bringen wir den Schülern immer noch bei, die schriftliche Division manuell durchzuführen, aber was nützt das, wenn sie einen Taschenrechner verwenden? Mit der Codierung ist es ähnlich. Welche grundlegenden Elemente halten wir für wichtig, um zu verstehen, was vor sich geht?“ sagt McGinn.

Zu diesen technischen Grundlagen gehören unter anderem Compiler, Computerarchitektur, Datenbanken, Speichermanagement und Betriebssysteme. „Entwickler überspringen vielleicht das gründliche Erlernen dieser Konzepte, weil Code-LLMs sie abstrahieren“, sagt El Maghraoui. Es ist jedoch wichtig, die inneren Abläufe der Softwareentwicklung zu verstehen, da diese Auswirkungen auf die Funktionalität und Leistung des Quellcodes haben, fügt sie hinzu.

Und obwohl Code-LLMs den kognitiven Aufwand durch die Automatisierung sich wiederholender Aufgaben reduzieren können, haben sie auch das Potenzial, die „kognitive Atrophie“ zu verstärken, wie El Maghraoui es nennt. Sie vergleicht es mit der zunehmenden Nutzung von GPS, die unseren natürlichen Orientierungssinn untergräbt. „Wenn Entwickler sich stark auf Codevorschläge verlassen, werden sie im Debuggen weniger versiert sein. Code-LLMs können unsere Fähigkeit, algorithmisch zu denken, schwächen, wenn wir sie nicht mit grundlegender Praxis oder grundlegendem Wissen ausgleichen.“

Während Code-LLMs voranschreiten, werden sie neue Funktionen und sogar neuartige Anwendungsfälle vorstellen, wie der Vibe-Coding-Trend zeigt. Was erwartet diese Modelle also in der Zukunft? Unsere Experten geben ihre Prognosen ab.

Die Welt spricht davon, dass KI-Agenten die Zukunft der Arbeit in fast jeder Branche verändern werden - auch in der Softwareentwicklung.

„Ich sehe den Wandel hin zu diesen Multiagenten-Codierungssystemen mit Codebasen mit automatischer Fehlerbehebung“, sagt El Maghraoui. Diese agentischen KI-Systeme nehmen bereits Gestalt an. Zum Beispiel können IBMs Software Engineering (SWE)-Agenten GitHub-Probleme autonom lösen, indem sie zunächst die Stelle der Fehler in einer Codebasis „lokalisieren“ und dann diese Codezeilen bearbeiten, um sie zu beheben.

McGinn hofft auf eine energieeffizientere Strategie, „bei der nicht alles vom größten Modell erledigt wird, sondern wir mit einem kleineren agentenbasierten Ansatz Energie sparen können“, der vorsieht, dass verschiedene Agenten spezifische Programmieraufgaben erfüllen.

Panda freut sich ebenso darauf, kleine Sprachmodelle (SLMs) wie Granite Code auch auf ressourcenbeschränkten Geräten wie Laptops und Edge-Geräten verfügbar zu machen. „Gleichzeitig gibt es einige Dinge, die für SLMs schwierig zu lösen sind, sodass dann die größeren Granite-Modelle ins Spiel kommen. Es ist ein Gleichgewicht zwischen mehreren Modellen, nicht nur ein einziges Modell, das alles löst.“

Die Integration von kontextbezogenem Gedächtnis und Argumentation in Code-LLMs ist eine weitere Verbesserung, auf die man achten sollte, bemerkt El Maghraoui. „Sie können sich an die gesamte Geschichte des Projekts und seine Entwicklung erinnern. So können wir bessere Vorschläge für die Zukunft machen.“

Die Argumentationskomponente hilft bei „langfristigen Aufgaben“, wie Panda es nennt. „Code-LLMs werden mit Ihren Code-Repositories interagieren, um viele Aktionen nacheinander auszuführen, nicht nur eine einmalige Aktion. Nur wenn Ihr Code-LLM über starke logische Fähigkeiten verfügt, kann es diese Aufgaben erfüllen.“

Heutige integrierte Entwicklungsumgebungen (IDEs) integrieren Codemodelle und Codierungsassistenten als Dienste oder Plug-ins. Doch die IDEs von morgen könnten sich in Richtung KI-nativer Entwicklungsumgebungen entwickeln. „Wir werden sehen, dass diese IDEs von Grund auf mit Code-LLMs neu gestaltet werden – nicht nur als Plug-ins, sondern als Teil ihres Kerns“, sagt El Maghraoui.

Sie sieht auch die zunehmende Bereitstellung von Code-LLMs in privater Infrastruktur als wachsenden Trend. Zum Beispiel unterstützt der Mistral Code KI-Assistent, angetrieben von Codestral und Devstral, die lokale Bereitstellung.

„Private Bereitstellungen für diese Code-LLMs werden durch Leistung, Kosten und Datenschutzbedenken beschleunigt“, sagt El Maghraoui. „Unternehmen möchten vermeiden, dass proprietärer Code an APIs von Drittanbietern gesendet wird. Private Bereitstellungen stellen sicher, dass ihr Quellcode, interne Bibliotheken und Stack-Traces niemals das interne Firmennetzwerk verlassen. Es gibt auch Probleme bei der Einhaltung von Vorschriften, insbesondere im Finanz- oder Gesundheitswesen, und die Kosten für die Ausführung von Anwendungsfällen mit hohem Durchsatz intern können im großen Maßstab günstiger sein.“

Das Schreiben von Code und das Erstellen von Tests sind unterschiedliche Bestandteile des Softwareentwicklungsprozesses. Satoh stellt sich vor, dass Code-LLMs diese beiden Phasen nahtlos miteinander verbinden und sowohl bei der Codegenerierung als auch bei der Testgenerierung behilflich sind.

„Wir sollten sie mit demselben Modell verbinden, um ein nahtloses Produkt zu schaffen“, sagt sie. Satoh geht sogar noch weiter und prognostiziert Code-Modelle, die „den gesamten Softwareentwicklungszyklus unterstützen“, einschließlich früherer Phasen wie Anforderungsspezifikation und Design.

Doch egal, wohin uns diese wachsende Ära des gemeinsam mit Maschinen verfassten Codes führt, El Maghraoui bleibt vorsichtig, aber optimistisch. „Es ist wie ein Messer, das zwei Seiten hat. Es könnte etwas sein, das uns als Entwicklern schadet, oder etwas, das uns hilft. Daher ist es wirklich wichtig zu verstehen, wie man diese Code-LLMs richtig einsetzt, damit man seinen Vorsprung nicht verliert, sondern kreativer wird.“ Und diejenigen, die voraussichtlich erfolgreich sein werden, so ihre Überzeugung, werden „Entwickler und Unternehmen sein, die diese Workflows annehmen und KI nicht nur als Werkzeug, sondern als Partner behandeln“.