KI in der Softwareentwicklung: Einsatz im SDLC und ein überprüfbarer Pilot
KI kann Anforderungen klären, Entwürfe diskutieren, Code und Tests vorschlagen und Wartungsaufgaben vorbereiten. Ob sie Ihre Softwareentwicklung verbessert, zeigt sich erst an einer fachlich akzeptierten Änderung einschließlich Prüfung und Nacharbeit. Beginnen Sie deshalb mit begrenzten Aufgaben, unabhängigen Akzeptanzkriterien und einem Pilot, der den vollständigen Entwicklungsprozess betrachtet.
Was bedeutet KI in der Softwareentwicklung?
Gemeint ist hier die Verwendung von KI als Werkzeug im Entwicklungsprozess: um eine Schnittstelle zu erklären, eine Lösungsskizze zu prüfen oder eine Änderung vorzubereiten. Davon zu unterscheiden ist die Entwicklung eines Produkts, das selbst KI-Funktionen enthält. Auch eine gewöhnliche Fachanwendung ohne Sprachmodell kann mit KI-Unterstützung gebaut und gewartet werden.
Die Arbeitsweise bestimmt, wie viel Kontrolle Sie unmittelbar ausüben. Eine Vervollständigung in der Entwicklungsumgebung schlägt einzelne Codepassagen vor. Ein Chat-Assistent hilft beim Erklären und Entwerfen; Sie übernehmen seine Vorschläge in Ihren Arbeitsablauf. Ein Coding-Agent kann in einem eingerichteten Arbeitsraum Dateien ändern, Befehle ausführen und einen Änderungsvorschlag vorbereiten. Mit mehr Handlungsmöglichkeiten wächst der Bedarf an klaren Aufgaben, Zugriffsgrenzen und nachvollziehbaren Ergebnissen.
Unter „Vibe Coding“ wird häufig eine stark sprachgesteuerte, explorative Erstellung von Software verstanden. Für einen verworfenen Prototyp kann diese Arbeitsweise schnell zu einer sichtbaren Idee führen. Sobald echte Daten, externe Nutzer oder bestehende Systeme betroffen sind, müssen Sie weiterhin Verhalten, Berechtigungen, Fehlerbehandlung und Wartbarkeit verstehen. Ein überzeugender Bildschirm ist noch kein geprüftes Produkt.
Der Software Development Life Cycle, kurz SDLC, umfasst die Arbeit von der fachlichen Anforderung bis zum Betrieb und der nächsten Verbesserung. Wenn nur die Codeerstellung schneller wird, aber Anforderungen unklar bleiben oder Reviews warten, kann der Engpass unverändert bestehen. Betrachten Sie KI deshalb in jeder Phase zusammen mit dem Arbeitsergebnis, das die nächste Phase benötigt.
Wo KI im gesamten SDLC unterstützen kann
Das folgende Arbeitsmodell verbindet sechs Phasen. Sie laufen in der Praxis oft parallel oder wiederholt. Ein hypothetisches Beispiel begleitet sie: Eine bestehende Bestell-API soll eine optionale Kundenreferenz namens client_reference entgegennehmen und zurückgeben. Das bisherige Verhalten und die Autorisierung sollen erhalten bleiben.
1. Anforderungen: aus einer Idee überprüfbares Verhalten machen
KI kann ein Ticket zusammenfassen, mehrdeutige Begriffe markieren und mögliche Grenzfälle sammeln. Als Eingaben benötigt sie vorhandene Fachregeln, aktuelle Schnittstellen und Beispiele. Im API-Beispiel sind Fragen offen: Ist eine leere Referenz zulässig? Wie lang darf sie sein? Dürfen Kunden die Referenz anderer Kunden sehen? Eine plausibel klingende Antwort aus dem Modell ersetzt keine Entscheidung des Fachbereichs.
Das Ergebnis dieser Phase ist ein bestätigter Anforderungssatz mit Beispielen und Akzeptanzkriterien. Eine fachlich verantwortliche Person entscheidet, welches Verhalten gewünscht ist. Besonders hilfreich ist KI hier als kritischer Gesprächspartner: Sie soll Lücken aufdecken, bevor sie aus einer Vermutung Code erzeugt.
2. Entwurf und UX: Alternativen prüfen und Folgen sichtbar machen
Mit vorhandenen Architekturregeln kann KI Alternativen vergleichen: ein zusätzliches Datenbankfeld, eine Erweiterung des API-Schemas oder eine Darstellung im Bestellformular. Sie kann Entwürfe, Migrationsschritte und Fehlermeldungen vorbereiten. Sie kennt aber nicht automatisch sämtliche historischen Gründe für die bestehende Architektur.
Im Beispiel prüfen Sie, ob alte Clients die Antwort weiterhin verarbeiten können und wie Bestandsdaten ohne Referenz behandelt werden. Das Team bestätigt Datenmodell, Rückwärtskompatibilität und Bedienverhalten. Als überprüfbares Ergebnis bleiben eine kurze dokumentierte Entwurfsentscheidung, ein Schemaschritt und gegebenenfalls ein UI-Entwurf. So kann ein späteres Review gegen bestätigte Entscheidungen prüfen.
3. Implementierung: begrenzte Änderungen mit passendem Kontext
KI kann einen Änderungsvorschlag schreiben, bestehende Muster suchen oder wiederkehrenden Code anpassen. Geben Sie den relevanten Repository-Ausschnitt, die freigegebenen Regeln und die vorgesehenen Testbefehle mit. Eine Anweisung wie „modernisiere die API“ eröffnet viel mehr Spielraum als das abgegrenzte Referenzfeld.
Im Beispiel gehört die Änderung auf einen eigenen Branch. Das Team kontrolliert, ob sie nur die vereinbarten Stellen berührt, bestehende Autorisierung nutzt und keine neue Abhängigkeit ohne Anlass einführt. Das Ergebnis ist ein verständlicher Diff, also die nachvollziehbare Gegenüberstellung der geänderten Dateien. Auch elegant wirkender KI-Code muss zur Architektur und zum Wartungsmodell des Teams passen.
4. Tests und Review: unabhängig vom Vorschlag prüfen
KI kann Testfälle vorschlagen, Testdaten entwerfen und fehlgeschlagene Läufe erklären. Wenn dasselbe Modell jedoch Sollverhalten, Implementierung und Tests selbst festlegt, können alle drei denselben Irrtum enthalten. Eine grüne Testsuite bestätigt dann möglicherweise nur eine falsche Annahme.
Im API-Beispiel stammen die erwarteten Ergebnisse deshalb aus den zuvor bestätigten Akzeptanzkriterien. Ein Reviewer prüft normale Referenzen, Grenzlängen, fehlende Werte und den Zugriff verschiedener Kunden. Zusätzlich betrachtet er Migration, Fehlerantworten und unbeabsichtigte Änderungen. Das Arbeitsergebnis dieser Phase ist eine begründete fachliche und technische Freigabe samt nachvollziehbaren Prüfergebnissen.
5. Release und Betrieb: Änderung kontrolliert ausliefern
KI kann Releasehinweise, eine Checkliste oder einen Rollback-Entwurf vorbereiten. Ob die Änderung bereit für die Produktion ist, entscheidet der bestehende Freigabeprozess. Zugang zu einem Entwicklungsrepository ist kein Grund, einem Agenten zugleich produktive Datenbank- oder Deploymentrechte zu geben.
Für das Referenzfeld prüfen Sie die Reihenfolge von Schemaänderung und Anwendungsauslieferung. Bestimmen Sie, wie ein fehlerhaftes Release zurückgenommen werden kann und welche Signale danach betrachtet werden: beispielsweise neue Validierungsfehler oder abweichende Antwortformate. Ein erfolgreich ausgeführter Deploymentbefehl sagt allein noch nichts über das fachliche Verhalten aus.
6. Wartung, Support und Feedback: Erkenntnisse zurückführen
KI kann anonymisierte Fehlerberichte strukturieren, einen reproduzierbaren Fall ausarbeiten oder Dokumentationslücken auffinden. Ein Supportfall sollte dabei in eine überprüfbare Fragestellung überführt werden. Unbereinigte Logs können sensible Daten enthalten; verwenden Sie den dafür freigegebenen Datenumfang.
Im Beispiel melden Nutzer vielleicht, dass Leerzeichen in der Referenz anders behandelt werden als erwartet. Das Team entscheidet, ob ein Fehler oder eine neue Anforderung vorliegt. Aus dieser Entscheidung entstehen ein neuer Test, eine gezielte Änderung und aktualisierte Dokumentation. Dokumentation begleitet somit sämtliche Phasen und hält zugleich fest, was Menschen tatsächlich bestätigt haben.
Was Produktivitätsstudien tatsächlich zeigen
Eine einzelne Prozentzahl sagt wenig über Ihr Team aus, solange Aufgabe, Werkzeugstand und Messgröße fehlen. In einem kontrollierten Copilot-Experiment von 2023 sollten Entwickler einen HTTP-Server in JavaScript implementieren. Die Gruppe mit Zugang zu Copilot benötigte für diese konkrete Aufgabe im Mittel 55,8 Prozent weniger Zeit. Das war ein Versuch mit einem begrenzten Aufgabentyp, kein Nachweis für sämtliche Arbeit in einem produktiven Entwicklungsprozess.
METR untersuchte 2025 einen anderen Kontext: 16 erfahrene Entwickler bearbeiteten 246 reale Aufgaben in ihnen vertrauten Open-Source-Repositories. Ob KI erlaubt war, wurde zufällig zugeteilt. In diesem Versuch dauerte die Bearbeitung mit KI im Mittel 19 Prozent länger. Vertrautheit mit dem System, hohe Qualitätsanforderungen und die damaligen Werkzeuge gehören zur Einordnung dieses Befunds.
Der aktuelle Vorbehalt ist ebenso wichtig: Im METR-Update vom 24. Februar 2026 beschreiben die Forschenden Auswahl- und Messprobleme bei neueren Untersuchungen. Entwickler wollten teilweise nicht mehr ohne KI arbeiten; parallele Agenten erschwerten die Zeitmessung. Die neuen Daten erlauben daher keine belastbare allgemeine aktuelle Effektgröße. Die ältere Verlangsamungszahl ist keine heutige Universalprognose.
Die Werte dieser Studien lassen sich weder mitteln noch direkt aufeinander übertragen. DORA 2025 betrachtet den organisatorischen Zusammenhang und beschreibt KI als Verstärker vorhandener Stärken und Schwächen. Für Ihre Entscheidung bedeutet das: Messen Sie den Weg zur akzeptierten Änderung in Ihrer Umgebung und erklären Sie, wodurch ein Unterschied entsteht.
Welche Leitplanken vor dem ersten KI-Auftrag stehen
Definieren Sie zunächst, welches Material ein Werkzeug verarbeiten darf. Dazu zählen Quellcode, Tickets, Kundendaten und Logs ebenso wie Inhalte aus verbundenen Systemen. Prüfen Sie Vertrag, Trainingsnutzung, Aufbewahrung und den vorgesehenen Betriebsmodus des konkreten Produkts. Die Erlaubnis für einen Chatdienst überträgt sich nicht automatisch auf einen Agenten mit Terminal und Repository-Zugriff.
Begrenzen Sie den Arbeitsraum auf die Aufgabe. Ein Agent für ein API-Feld braucht keinen produktiven Administrationszugang. Nutzen Sie getrennte Entwicklungsumgebungen, passende Repository-Rechte und kontrollierte Geheimnisverwaltung. Überprüfen Sie auch zusätzliche Werkzeuge und Integrationen: Ein eingebundenes Tool kann Daten lesen oder Aktionen auslösen, die der ursprüngliche Auftrag nicht benötigt.
Erhalten Sie bestehende Prüfungen. Änderungen an Autorisierung, Abhängigkeiten, Datenbankmigrationen und Fehlerbehandlung verdienen besondere Aufmerksamkeit. Ein Test darf nicht still entfernt werden, damit der vorgeschlagene Code besteht. Lassen Sie die Änderung gegen Ihre üblichen fachlichen, technischen und Sicherheitskriterien prüfen und klären Sie, wer die endgültige Freigabe erteilt.
Als übergreifender Rahmen kann das NIST Secure Software Development Framework, Version 1.1, helfen. Es enthält sichere Entwicklungspraktiken, die sich in unterschiedliche Lebenszyklen integrieren lassen. Es ist keine Zertifizierung eines KI-Werkzeugs. Auch GitHubs Hinweise zu Coding-Agenten benennen mögliche falsche oder unsichere Ergebnisse und empfehlen menschliche Prüfung und Tests vor dem Merge. Diese Kontrollen bleiben Teil der Arbeit.
Einen überprüfbaren Pilot in Ihrer Softwareentwicklung aufsetzen
Ein Pilot soll eine begrenzte Entscheidung ermöglichen: Bei welchen Aufgaben verbessert ein freigegebenes KI-Werkzeug die Lieferung, und welche Bedingungen braucht es dafür? Der folgende Vier-Wochen-Plan ist ein eigener Vorschlag, kein empirisch bestätigter Standardzeitraum. Wählen Sie einen Umfang, der zu Ihrem Team passt; eine kleine Stichprobe bleibt eine lokale Orientierung.
Vorbereitung: Aufgabe, Vergleich und Abnahme festlegen
Wählen Sie wiederkehrende, gut überprüfbare Aufgaben mit vorhandenem Kontext, etwa kleine Validierungen, dokumentierte Fehlerbehebungen oder begrenzte Refactorings. Halten Sie Repository, Testbefehle, Werkzeug- und Modellstand fest. Legen Sie die fachliche Abnahme und erlaubten Zugriffe fest, bevor die Umsetzung beginnt. Reservieren Sie Reviewerzeit, damit eine Warteschlange den Vergleich nicht verdeckt.
Für einen Vergleich eignen sich verschiedene, ähnlich schwierige Aufgaben mit und ohne KI-Unterstützung. Teilen Sie diese vorab zu und berücksichtigen Sie Erfahrung mit dem Repository. Dieselbe Aufgabe zweimal zu lösen erzeugt einen Lerneffekt. Ein Vergleich aktueller kleiner Tickets mit alten Großprojekten wäre ebenfalls wenig aussagekräftig. Dokumentieren Sie Unterschiede, die Sie nicht kontrollieren können.
Ein Ticket, an dem die Abnahme verständlich wird
Hypothetischer Pilotauftrag: Ergänzen Sie im bestehenden Bestell-Endpunkt das optionale Feld client_reference. Zulässig sind 1 bis 40 Zeichen; fehlt das Feld, bleibt das bisherige Verhalten erhalten. Zu lange oder explizit leere Werte ergeben die vorhandene Validierungsfehlerantwort. Die Antwort gibt eine gespeicherte Referenz ausschließlich für die eigenen Bestellungen des angemeldeten Kunden zurück.
Nutzen Sie die bestehenden Validierungs- und Autorisierungsmuster. Keine neue Abhängigkeit, keine Änderung der Zugriffskontrolle. Legen Sie die Schemaänderung und ihre Behandlung von Bestandsdaten offen. Vor der Umsetzung werden unabhängige Fälle für fehlend, leer, Länge 1, Länge 40, Länge 41 und fremde Bestellung bestätigt. Bestehende Tests bleiben erhalten.
Der Auftrag definiert erwünschtes Verhalten und Grenzen; er schreibt keine konkrete Implementierung vor. Ein Reviewer kann deshalb die Lösung verstehen und anhand unabhängiger Erwartungen abnehmen. Bei einer ungeklärten Fachfrage pausiert die Umsetzung, bis eine verantwortliche Person entschieden hat.
Durchführung: den gesamten Weg erfassen
Erfassen Sie pro Versuch die Zeit vom arbeitsfähigen Ticket bis zur akzeptierten Änderung und zusätzlich die aktive Arbeitszeit der Beteiligten. Halten Sie Einweisung, Kontextaufbereitung, Prüfung, Korrekturen und erneute Tests fest. Agentenlaufzeit ist nicht automatisch eingesparte Entwicklerzeit: Währenddessen kann eine Person auf ein Ergebnis warten oder andere Arbeit erledigen.
Führen Sie auch verworfene Versuche auf. Wird ein Auftrag nach mehreren Schleifen manuell beendet, gehören verbrauchtes Kontingent und Betreuungszeit zur Bewertung. Prüfen Sie außerdem, ob Fehler erst nach der Abnahme auffallen. Ein schneller Merge mit späterem Korrekturaufwand beantwortet eine andere Frage als eine dauerhaft akzeptierte Änderung.
Auswertung: Unterschiede erklären und vorab definierte Stopps nutzen
Betrachten Sie Durchlaufzeit, aktive Teamzeit, Revieweraufwand und Qualität zusammen. Codezeilen und die Zahl erzeugter Tests beschreiben Output, nicht die fachliche Güte. Fragen Sie bei jedem Unterschied: Wurde die Aufgabe schneller geklärt? Entstand mehr Nacharbeit? Fehlte Kontext? Stand ein Reviewer nicht zur Verfügung? Bei wenigen Aufgaben sind diese Beobachtungen oft nützlicher als eine scheinpräzise Prozentzahl.
Setzen Sie vorab Stopppunkte für unerlaubte Zugriffe, entfernte Prüfungen, wiederholt falsches Sollverhalten und ein ausgeschöpftes Versuchslimit. Ein solcher Stopp liefert Erkenntnis über die aktuelle Aufgabenform oder Konfiguration. Skalieren Sie erst die Arbeitsweise, für die Aufgaben, Kontrollen und Abnahme nachvollziehbar funktionieren.
Was sich für Team und Werkzeugauswahl verändert
KI verschiebt Arbeit zwischen Schreiben, Erklären und Prüfen. Planen Sie deshalb Zeit ein, um gute Aufgaben zu formulieren und vorgeschlagene Änderungen gemeinsam zu besprechen. Gerade weniger erfahrene Entwickler benötigen Gelegenheit, Verhalten und Architektur zu erklären. Ein Werkzeug, das sofort eine Lösung liefert, ersetzt diese Lernschritte nicht.
Bei der Auswahl helfen konkrete Fragen: Kann das Werkzeug den relevanten Kontext erhalten? Lassen sich Daten und Rechte passend begrenzen? Sind Änderungen und Verbrauch nachvollziehbar? Passt es zu Repository, Tests und Freigaben? Die beste Wahl kann für enge Assistenz anders ausfallen als für einen delegierten Auftrag. Ein isolierter Benchmark oder eine umfangreiche Funktionsliste beantwortet diese Betriebsfragen nicht.
Wenn Ihr Pilot in bestehende Toolchain, Governance und Enablement überführt werden soll, beschreibt eBiz, wie Sie einen AI SDLC kontrolliert einführen können. Die tragfähige Grundlage dafür ist ein beobachteter Arbeitsablauf mit klarer Abnahme, verlässlichen Kontrollen und einem Team, das die Ergebnisse versteht.