KI in der Softwareentwicklung: sicherer LLM-Workflow

Ein Sprachmodell erzeugt in Sekunden eine Komponente, ergänzt eine Konfiguration oder erklärt ein fremdes Framework. Dann läuft der Test nicht. Oder die Änderung funktioniert zwar, hinterlässt aber ein Konstrukt, das niemand im Team mehr anfassen möchte.

Genau dort beginnt die eigentliche Arbeit mit KI in der Softwareentwicklung. Große Sprachmodelle können Entwicklungsprozesse spürbar beschleunigen, vor allem bei Erkundungen, Prototypen und dem Verständnis gewachsener Systeme. Sie verändern aber auch die Qualitätsarbeit: Code Reviews, Tests, Refactoring, fachliche Sprache und kurze Feedbackzyklen gewinnen weiter an Gewicht.

Ein LLM verhält sich im Alltag wie ein produktiver, aber unzuverlässiger Kollaborationspartner. Diese Einordnung entscheidet darüber, ob ein Team gezielt davon profitiert oder technischen Ballast einsammelt.

Warum KI-gestützte Entwicklung eine andere Denkweise verlangt

Traditionelle Softwarewerkzeuge arbeiten weitgehend deterministisch. Eine IDE benennt eine Klasse um, ein Compiler meldet Fehler, ein Test liefert bei identischem Zustand dasselbe Ergebnis. Das macht Werkzeuge berechenbar und erlaubt sehr präzise Arbeitsabläufe.

LLMs funktionieren anders. Derselbe Auftrag kann leicht andere Ergebnisse liefern. Das Modell kann plausible Erklärungen geben, obwohl es Kontext missverstanden hat. Es kann behaupten, Tests seien erfolgreich gelaufen, obwohl der tatsächliche Testlauf Fehler zeigt. Auch einfache Angaben wie ein aktuelles Datum oder der passende Konfigurationswert können falsch sein.

Diese Eigenschaft wirkt bis in den Betrieb hinein. Sie beeinflusst, wie Teams KI-generierten Code prüfen, einführen und langfristig verantworten.

Von exakten Befehlen zu Wahrscheinlichkeiten und Toleranzen

Bei klassischer Programmierung wird Code als präzise Anweisung formuliert. Bei generativer KI beschreibt ein Prompt zunächst eine Absicht. Das Ergebnis bleibt eine Wahrscheinlichkeitsausgabe, deren Qualität vom Kontext, vom Modell, von der Aufgabenstellung und von der Formulierung abhängt.

Für die Praxis hilft ein Gedanke aus anderen Ingenieursdisziplinen: Mit Toleranzen rechnen. Wer ein System baut, das auf eine sehr schmale, zufällig passende Antwort eines Modells angewiesen ist, bewegt sich nahe an einer riskanten Grenze. Das gilt besonders bei Sicherheit, Berechtigungen, personenbezogenen Daten und geschäftskritischen Regeln.

Bei KI-Assistenten im Unternehmen gehört dazu auch ein sauberer Zugriff auf Wissen und Daten. Ein Assistent darf hilfreiche Informationen finden, ohne interne Inhalte an Personen ohne Berechtigung weiterzugeben. Der Beitrag Berechtigungen und Datenschutz beim KI-Assistenten zeigt, welche Regeln dafür in der Praxis nötig sind.

Wofür LLMs in der Softwareentwicklung besonders nützlich sind

Der Nutzen von KI verteilt sich nicht gleichmäßig über alle Aufgaben. Besonders stark ist sie dort, wo Menschen Optionen erkunden, sich in unbekannte Umgebungen einarbeiten oder schnell einen ersten Arbeitsstand benötigen.

1. Prototypen und schnelle Explorationen

Ein LLM kann aus einer groben Idee in kurzer Zeit einen interaktiven Prototypen erzeugen. Das ist wertvoll, wenn ein Team Varianten vergleichen möchte: Wie könnte ein Ablauf aussehen? Welche Darstellung vermittelt den Fortschritt besser? Welche API-Struktur fühlt sich für erste Nutzer sinnvoll an?

Solche Ergebnisse müssen nicht elegant oder langfristig wartbar sein. Ihr Zweck liegt im Lernen. Mehrere kleine Entwürfe ermöglichen frühes Feedback, bevor ein Team viel Zeit in eine einzelne Richtung investiert.

Geeignete Beispiele:

• Ein wegwerfbarer Klickprototyp für einen neuen Workflow
• Ein kleines Skript für eine einmalige Datenaufbereitung
• Ein Startprojekt, um ein unbekanntes Framework auszuprobieren
• Varianten einer Oberfläche, die intern verglichen werden sollen
• Ein experimenteller Adapter für eine API

Das Ergebnis sollte klar als Experiment gekennzeichnet sein. Sonst wird aus dem schnellen Versuch schleichend ein Produktivsystem, das niemand verstanden oder bewusst gestaltet hat.

2. Einarbeitung in unbekannte Technologien

Wer sich in eine neue Sprache, Bibliothek, Game Engine oder API einarbeitet, kann mit einem LLM Fragen stellen, Beispiele anfordern und Zusammenhänge erkunden. Das reduziert die Hürde, erste Schritte zu machen.

Hilfreich ist dabei eine aktive Haltung: Kleine Experimente durchführen, die Erklärung am realen Verhalten prüfen und Rückfragen stellen. Ein Chat ersetzt weder Dokumentation noch fachliche Quellen, kann aber beim Orientieren beschleunigen.

Gute Fragen für diese Phase:

• Welche kleinste Projektstruktur brauche ich für einen funktionierenden Einstieg?
• Welche Konzepte dieser Bibliothek sind für diese Aufgabe relevant?
• Welche Annahmen stecken hinter diesem Beispielcode?
• Welche Alternativen gibt es und unter welchen Bedingungen passen sie?
• Wie kann ich die vorgeschlagene Lösung mit einem kleinen Test überprüfen?

3. Legacy-Code verstehen

Eine besonders praktische Anwendung liegt in gewachsenen Systemen. In großen Codebasen fehlen oft Übersicht, aktuelle Dokumentation und Menschen, die jede historische Entscheidung erklären können. Datenflüsse, Abhängigkeiten und fachliche Regeln verteilen sich über Jahre hinweg auf viele Module.

LLMs können hier helfen, Code zu strukturieren, Fragen vorzubereiten und relevante Stellen schneller zu finden. Besonders nützlich wird das in Verbindung mit einer belastbaren Codeanalyse: Semantische Informationen über das System können beispielsweise als Graph aufbereitet werden. Ein Modell erhält dann gezielt Kontext, statt bloß auf Basis einzelner Dateiausschnitte zu raten.

Typische Fragen lauten:

• Welche Teile des Systems lesen oder verändern dieses Datenfeld?
• Welche Aufrufe folgen auf diesen Prozessschritt?
• Wo werden Sonderfälle für einen bestimmten Geschäftsprozess behandelt?
• Welche Komponenten hängen von dieser Schnittstelle ab?

Das ist ein sinnvoller Einstieg in die Modernisierung, aber keine Freigabe für unkontrollierte Änderungen. Mehr dazu erklärt KI und Legacy-Code: was 2026 tatsächlich funktioniert.

Was Vibe Coding ist und wo seine Grenze liegt

Unter Vibe Coding wird häufig eine Arbeitsweise verstanden, bei der Menschen vor allem beschreiben, was entstehen soll, und den erzeugten Code kaum oder gar nicht prüfen. Hauptsache, die Anwendung scheint zunächst zu funktionieren.

Für flüchtige Experimente kann das angemessen sein. Ein Prototyp, ein persönliches Hilfsskript oder ein einmaliger Entwurf darf eine kurze Lebensdauer haben. Die Kosten späterer Änderungen sind dann begrenzt.

Für Software mit langfristiger Verantwortung ist dieser Ansatz riskant. Ungeprüfter Code enthält oft unnötige Komplexität, schwer nachvollziehbare Abhängigkeiten oder Strukturentscheidungen, die sich später kaum gezielt verändern lassen. Wenn Anpassungen nur noch über eine vollständige Neuerzeugung möglich sind, sinkt die Kontrolle über die Wartbarkeit spürbar.

Das fehlende Element: die Lernschleife

Softwareentwicklung besteht aus einer fortlaufenden Schleife: Idee formulieren, umsetzen, Verhalten beobachten, Fehler finden, Struktur verbessern, erneut prüfen. In dieser Schleife entsteht Verständnis.

Wer die Ausgabe eines LLMs ungeprüft übernimmt, überspringt einen Teil dieses Lernens. Das Problem zeigt sich erst später: Eine kleine Anpassung wird plötzlich zu einer vollständigen Neuerzeugung, weil niemand weiß, warum der vorhandene Code so aufgebaut ist.

Eine tragfähige Regel lautet: Generierten Code darf man übernehmen, um sein Verhalten zu untersuchen. Danach sollte klar sein, warum er funktioniert, welche Annahmen er trifft und wie er sich ändern lässt.

Ein sicherer Workflow für KI-generierten Code

LLMs entfalten ihren Nutzen eher in kleinen, überprüfbaren Arbeitspaketen als bei großen, unkontrollierten Aufträgen. Das passt gut zu einer inkrementellen Entwicklung mit kurzen Feedbackzyklen.

Schritt 1: Aufgabe klein schneiden

Am Anfang steht ein enger Auftrag. Statt eine ganze Anwendung oder einen umfangreichen Umbau auf einmal zu verlangen, wird eine kleine Änderung beschrieben: eine Funktion, ein klar abgegrenzter Ablauf, ein Datenmodell oder ein Testfall.

Je kleiner der Ausschnitt, desto leichter lassen sich Ergebnis, Risiken und Nebenwirkungen beurteilen.

Schritt 2: Kontext präzise bereitstellen

Ein Modell arbeitet besser, wenn Begriffe, Regeln und Grenzen klar sind. Dazu gehören:

• fachliche Anforderungen und Akzeptanzkriterien
• relevante Schnittstellen und Datenstrukturen
• Projektkonventionen für Namen, Fehlerbehandlung und Architektur
• bestehende Tests oder Beispiele
• klare Verbote, etwa keine Änderung öffentlicher APIs

In komplexen Domänen kann eine gemeinsame, präzise Fachsprache sehr viel bewirken. Begriffe aus Buchhaltung, Logistik, Versicherungen oder anderen Fachbereichen sollten im Prompt, im Code und in der Kommunikation möglichst konsistent verwendet werden. So sinkt die Gefahr, dass Anforderungen durch mehrere Übersetzungsschichten verzerrt werden.

Schritt 3: Output wie einen Pull Request behandeln

KI-generierter Code braucht ein kritisches Review. Eine hilfreiche Denkfigur: Das Modell liefert die Änderung eines sehr produktiven, aber wenig verlässlichen Mitarbeiters. Der Umfang kann beeindruckend sein. Die Prüfung bleibt dennoch vollständig erforderlich.

Review-Checkliste:

• Erfüllt die Änderung die konkrete Anforderung?
• Passt sie zu Architektur und Konventionen des Projekts?
• Sind Namen, Kontrollflüsse und Fehlerfälle verständlich?
• Wurden unnötige Abhängigkeiten eingeführt?
• Gibt es Sicherheits-, Datenschutz- oder Berechtigungsrisiken?
• Ist die Lösung kleiner und einfacher als nötig, oder produziert sie überflüssige Komplexität?
• Existieren Tests für das erwartete Verhalten?

Wenn die Menge erzeugten Codes steigt, geraten Reviews leicht unter Druck. Teams brauchen dann bessere Prüfmechanismen statt bloß mehr Durchsatz. Der Beitrag Code Review skaliert nicht mehr behandelt dieses Spannungsfeld.

Schritt 4: Tests tatsächlich ausführen

Ein Modell kann Testcode schreiben, Testausgaben interpretieren und sinnvolle Fälle vorschlagen. Es kann aber auch falsche Behauptungen über den Zustand eines Projekts machen. Daher gilt: Testresultate stammen aus der tatsächlichen Ausführung in der Entwicklungsumgebung, CI-Pipeline oder einem anderen verlässlichen System.

Besonders wertvoll sind Tests, die das bestehende Verhalten festhalten, bevor Änderungen erfolgen. Das betrifft ältere Codebasen genauso wie neue Funktionen.

Mindestens prüfen:

• Unit-Tests für die neue oder geänderte Logik
• Integrations- oder Schnittstellentests bei Systemgrenzen
• Fehlerfälle und ungültige Eingaben
• Regressionen in angrenzenden Funktionen
• manuelle Prüfung dort, wo Nutzererlebnis oder Fachprozess relevant sind

Schritt 5: Refactoring in kleinen Schritten

Refactoring meint verhaltensbewahrende Änderungen an der internen Struktur eines Programms. Eine Klasse umzubenennen, eine zu lange Funktion aufzuteilen oder doppelte Logik zusammenzuführen, sind typische Beispiele. Der Wert liegt in kleinen Schritten, die sich jeweils leicht prüfen lassen und sich zu größeren Verbesserungen zusammensetzen.

KI erzeugt häufig mehr Code in kürzerer Zeit. Damit wächst auch die Menge an Code, dessen Qualität beurteilt und verbessert werden muss. Refactoring wird dadurch eher wichtiger.

Viele Umbauten sollten weiterhin mit den deterministischen Funktionen einer IDE erfolgen. Eine Umbenennung oder das Verschieben einer Funktion ist dort oft zuverlässiger und schneller als eine ausführliche natürliche Sprachbeschreibung an ein LLM. KI kann jedoch bei der Vorbereitung helfen, etwa beim Finden von Kandidaten für Vereinfachungen oder beim Erklären komplizierter Bereiche.

LLMs mit deterministischen Werkzeugen kombinieren

Die stärkste Arbeitsweise entsteht häufig aus dem Zusammenspiel beider Welten. Das Sprachmodell hilft bei der Absicht, beim Einstieg und bei der Recherche. Deterministische Werkzeuge führen präzise Operationen aus und liefern überprüfbare Ergebnisse.

Ein mögliches Muster sieht so aus:

1. Ein LLM hilft, eine Änderung oder Abfrage zu formulieren.
2. Ein statisches Analysewerkzeug, eine IDE oder ein Migrationswerkzeug führt die konkrete Operation aus.
3. Das Team prüft den nachvollziehbaren Diff und die Testergebnisse.
4. Bei Abweichungen wird der nächste kleine Schritt angepasst.

Das ist besonders sinnvoll bei großen Codebasen, API-Migrationen, strukturellen Analysen und wiederholbaren Änderungen. Der Mensch erhält dabei verständliche Vorschläge, während das präzise Werkzeug die Änderung kontrollierbar umsetzt.

Spezifikationen: präziser schreiben, aber in kurzen Schleifen arbeiten

LLMs reagieren empfindlich auf unklare Anforderungen. Gute Spezifikationen, Beispiele und fachliche Begriffe können die Qualität der Ausgabe deutlich verbessern. Das heißt jedoch nicht, dass Teams wieder monatelang vollständige Lastenhefte verfassen sollten.

Große Vorabspezifikationen leiden weiterhin unter bekannten Problemen: Annahmen bleiben ungetestet, Details ändern sich, Rückmeldungen kommen spät. Sinnvoller sind dünne, schnelle Scheiben:

• den kleinsten fachlich sinnvollen Ausschnitt beschreiben
• eine Implementierung erstellen lassen oder selbst erstellen
• mit Tests und realem Feedback prüfen
• die Sprache, Regeln und Beispiele verbessern
• den nächsten Ausschnitt angehen

Die Spezifikation wird damit zu einem Arbeitsmittel im Dialog mit Fachseite, Team und Werkzeugen. Sie bleibt nah am Code, ohne mit ihm verwechselt zu werden.

KI in Enterprise-Software: Mehr Kontext, mehr Verantwortung

In etablierten Unternehmen sind Softwareentwickler oft nur ein Teil eines viel größeren Systems. Fachbereiche, regulatorische Vorgaben, historische Ausnahmen, alte Schnittstellen und Sicherheitsanforderungen prägen die Arbeit. Banken, Behörden, Airlines, Handel und Versicherungen bringen jeweils eigene Risikoprofile mit.

Ein kleines Team in einem neuen Produkt kann Experimente schneller durchführen als eine Organisation, deren Fehler erhebliche Folgen hätten. Innerhalb großer Unternehmen gibt es allerdings ebenfalls Unterschiede: Einige Bereiche testen neue Ansätze früh, andere müssen aus guten Gründen zurückhaltend sein.

Vor einem produktiven Einsatz sollten Teams deshalb klären:

• Welche Daten dürfen in das Modell oder in einen externen Dienst gelangen?
• Welche Ergebnisse brauchen menschliche Freigaben?
• Wo können falsche Antworten finanzielle, rechtliche oder sicherheitsrelevante Schäden verursachen?
• Welche Quellen, Tests und Nachweise sind erforderlich?
• Wie wird nachvollziehbar, welche Änderung von welchem Werkzeug erzeugt wurde?

Gerade bei wissensbasierten Assistenten ist eine plausible Antwort keine ausreichende Qualitätssicherung. Quellenzugriff, Rechteprüfung, Retrieval und klare Nachweise machen Antworten belastbarer. Dazu passen die Maßnahmen aus KI-Halluzinationen vermeiden: So werden Antworten im Betrieb belastbar.

Was sich an agiler Entwicklung mit KI ändert

KI erhöht die Geschwindigkeit, mit der Ideen in lauffähige Entwürfe überführt werden können. Daraus folgt kein Anlass, große Arbeitspakete zu bündeln. Kurze Zyklen bleiben ein wirksames Mittel gegen Fehlannahmen und unnötige Arbeit.

Ein Team kann die neue Geschwindigkeit nutzen, um häufiger Feedback zu erhalten: mehr Varianten eines Prototyps, frühere Tests einer Schnittstelle, kleinere Releases und schnellere Qualitätsverbesserungen. Der praktische Hebel liegt darin, die Zeit von einer Idee bis zu überprüfbarem Verhalten zu verkürzen.

Auch Warteschlangen verdienen Aufmerksamkeit. Lange Wartezeiten vor Review, Test, Freigabe oder Deployment machen den möglichen KI-Vorteil schnell zunichte. Qualität darf dabei nicht zum nachgelagerten Restschritt werden. Sie gehört in jede kleine Lieferung.

Welche Fähigkeiten Softwareentwickler weiterhin brauchen

KI verändert Werkzeuge und Arbeitsabläufe. Die Grundlagen guter Softwareentwicklung bleiben sehr gefragt:

• Fachliches Verständnis: erkennen, welches Problem tatsächlich gelöst werden soll.
• Kommunikation: mit Fachbereichen, Nutzern und anderen Entwicklern präzise arbeiten.
• Urteilsvermögen: plausible Vorschläge von tragfähigen Lösungen unterscheiden.
• Testing und Qualitätssicherung: Verhalten absichern, Fehler finden und Risiken begrenzen.
• Strukturdenken: Abstraktionen, Schnittstellen und verständliche Systeme gestalten.
• Lernfähigkeit: neue Werkzeuge ausprobieren, ihre Grenzen erkennen und Erkenntnisse weitergeben.

Rat für Junior-Entwickler

Berufseinsteiger sollten KI-Werkzeuge nutzen, aber ihre Antworten aktiv hinterfragen. Besonders hilfreich ist ein erfahrener Mentor oder ein Team, das Reviews erklärt und die Gründe hinter Architektur- und Qualitätsentscheidungen sichtbar macht.

Eine gute Übung besteht darin, nach jeder KI-Antwort weiterzufragen: Warum wurde dieser Ansatz gewählt? Welche Voraussetzungen gelten? Welche Alternative wäre möglich? Wie lässt sich die Behauptung testen? Diese Fragen fördern genau die Fähigkeiten, die ein Modell nicht zuverlässig ersetzt.

Häufige Fehler beim Einsatz von LLMs für Code

Zu große Aufgaben auf einmal delegieren

Umfangreiche Aufträge erzeugen große Diffs, viele Annahmen und schwierige Reviews. Kleine Aufgaben machen Fehler sichtbar, bevor sie sich über das System verteilen.

Code akzeptieren, weil er kompiliert

Kompilieren zeigt nur einen Teil der Wahrheit. Fachliche Korrektheit, Sicherheit, Wartbarkeit, Performance und Bedienbarkeit brauchen weitere Prüfungen.

LLM-Aussagen mit tatsächlichen Tool-Ergebnissen verwechseln

Ein Modellbericht ist kein Testlauf, keine Sicherheitsprüfung und keine verlässliche Quellenangabe. Verifikationen gehören in die dafür vorgesehenen Werkzeuge und Prozesse.

Prototypen unbemerkt in Produktion überführen

Ein schneller Entwurf darf chaotisch sein. Produktivcode braucht bewusstes Design, Tests, Betriebskonzepte und Verantwortlichkeiten. Diese Grenze sollte für alle Beteiligten sichtbar bleiben.

Generierten Code nicht verstehen wollen

Wer den Code später ändern, debuggen oder verantworten muss, braucht ein Modell seines Verhaltens im Kopf. Ohne dieses Verständnis werden selbst kleine Änderungen teuer und riskant.

Fazit: KI beschleunigt Entwicklung, Verantwortung bleibt beim Team

LLMs sind besonders stark beim Erkunden, Prototyping, Lernen und Verstehen komplexer Bestände. Sie können Entwicklungsarbeit beschleunigen, liefern aber keine automatische Garantie für korrekten, sicheren oder wartbaren Code.

Ein robuster KI-Workflow arbeitet in kleinen Schritten, verbindet präzise Spezifikationen mit Tests, prüft jeden relevanten Output kritisch und nutzt deterministische Werkzeuge für präzise Änderungen. Unter diesen Bedingungen wird KI zu einem Hebel für bessere Software, dessen Ergebnisse ein Team auch in zwei Jahren noch verantworten kann.