Schneller programmiert heißt noch nicht besser geliefert. Der DORA-Report 2025 beschreibt KI als Verstärker vorhandener organisatorischer Stärken und Schwächen. [1] [7] Für IT-Entscheider rückt damit eine Frage in den Mittelpunkt: Wie werden Architektur, Qualitätskontrollen und Betriebsprozesse so aufgestellt, dass zusätzlicher Code auch zusätzlichen Nutzen schafft? Der folgende Beitrag beleuchtet die technischen und organisatorischen Grundlagen.

Management Summary

Geschäftsnutzen statt Codevolumen: Bewerten Sie KI entlang des gesamten Lieferprozesses. DORA 2025 berichtet Zusammenhänge mit höherem Durchsatz, aber auch mit geringerer Lieferstabilität. [6] Schnelleres Programmieren allein ist kein ausreichender Erfolgsmaßstab.
Architektur als Führungsaufgabe: Definieren Sie Modulgrenzen, Schnittstellen und Verantwortlichkeiten. Wählen Sie Microservices nur bei nachvollziehbarem Bedarf; verteilte Systeme bringen zusätzlichen Entwicklungs- und Betriebsaufwand mit sich. [4] [8]
Plattformen als internes Produkt: Richten Sie wiederverwendbare Entwicklungs- und Betriebsdienste an den Bedürfnissen der Anwendungsteams aus. Der CNCF-Leitfaden stellt Nutzerorientierung und messbaren Plattformnutzen in den Mittelpunkt. [3]
Qualität nicht delegieren: Integrieren Sie Sicherheitsanforderungen, Reviews und Prüfungen in den Entwicklungszyklus. Das NIST SSDF bietet dafür einen technologieunabhängigen Orientierungsrahmen. [2]
Gezielt skalieren: Starten Sie mit einem begrenzten Anwendungsfall und klaren Erfolgskriterien. Investieren Sie anschließend dort, wo Prozesse und Plattformfähigkeiten den größten Nutzen versprechen – nicht allein in zusätzliche KI-Lizenzen. [1] [3]

Illustration Absmeier foto ki designer

KI-generierte konzeptionelle Illustration – modulare Softwarearchitektur, Qualitätsprüfungen und Cloud-Betrieb als zusammenhängender Entwicklungsprozess.

KI kann Code in kürzester Zeit erzeugen und Entwicklungsteams dabei helfen, Ideen schneller in funktionierende Software umzusetzen. Doch mehr Geschwindigkeit bedeutet nicht automatisch bessere Software. Ohne klare Architektur, standardisierte Prozesse und ein Verständnis für den späteren Betrieb können Systeme schnell unübersichtlich und schwer wartbar werden. [6]

Dag Dammann, Senior IT Consultant bei accompio, unterstützt Unternehmen dabei, Softwareentwicklung, Automatisierung und IT-Infrastruktur weiterzuentwickeln. Im Interview erklärt er, warum KI etablierte Architekturprinzipien nicht ersetzt, welche Rolle Cloud-Native-Ansätze und Platform Engineering spielen und wie Unternehmen KI sinnvoll in ihre Entwicklungsprozesse integrieren.

Das Wichtigste in Kürze

KI beschleunigt die Entwicklung, übernimmt aber nicht die Verantwortung für Architektur, Qualität und Betrieb.
Modulare Softwarearchitekturen reduzieren Komplexität und erleichtern es Menschen wie KI-Systemen, Code zu verstehen und weiterzuentwickeln.
Cloud-Native-Technologien, Container und Standards schaffen wiederverwendbare Grundlagen für Automatisierung und skalierbare Entwicklung.
T-Shaped Developer verbinden breites Wissen über den gesamten Entwicklungsprozess mit fachlicher Tiefe.
Klare Prozesse sind die Voraussetzung für erfolgreiche KI-Einführung: Unternehmen sollten klein anfangen und ihre Erfahrungen schrittweise ausbauen.
KI in der Softwareentwicklung: Experteninterview mit Dag Dammann

Im vollständigen Experteninterview erklärt Dag Dammann, Senior IT Consultant bei accompio, wie Unternehmen KI in der Softwareentwicklung sinnvoll einsetzen, technische Komplexität reduzieren und ihre Entwicklungsprozesse zukunftsfähig gestalten können.

Video ansehen: https://youtu.be/tYty00BlXrU

Mehr Code in kürzerer Zeit, aber wer behält den Überblick?

KI verändert die Softwareentwicklung vor allem durch Geschwindigkeit. Ideen lassen sich schneller in Programmcode übersetzen, Lösungen zügiger prototypisieren und bestehende Ansätze neu bewerten. Dadurch entstehen Möglichkeiten, Prozesse und technische Lösungen grundlegend zu überdenken.

Gleichzeitig verschwinden die bisherigen Herausforderungen nicht. Software muss weiterhin verständlich, wartbar und zuverlässig betreibbar sein. DORA empfiehlt, Tests kontinuierlich während des gesamten Lieferprozesses durchzuführen und schnelle, zuverlässige automatisierte Tests in die Bereitstellungspipelines einzubinden. [14] Das Google-SRE-Kapitel beschreibt Monitoring und Alarmierung für den laufenden Betrieb. [16]

Hier zeigt sich ein grundlegender Zielkonflikt aus dem DevOps-Umfeld: Entwicklung möchte neue Funktionen möglichst schnell bereitstellen, während der Betrieb Stabilität und Verfügbarkeit sicherstellen muss. KI kann die Entwicklung beschleunigen – doch ohne passende Automatisierung und Betriebsprozesse kann sich der Engpass lediglich verschieben. [6] [20]

Unternehmen sollten deshalb nicht allein messen, wie schnell Code entsteht. Entscheidend ist, ob die gesamte Wertschöpfung von der Idee über die Entwicklung und Bereitstellung bis zum Betrieb effizienter wird. [15] [20]

Modulare Architektur schafft Klarheit für Mensch und KI

Eine zentrale Grundlage für wartbare Software ist eine Architektur mit klar abgegrenzten Komponenten und Aufgaben. Statt ein einziges Werkzeug für möglichst viele Probleme zu entwickeln, sollten einzelne Komponenten konkrete Aufgaben übernehmen und sich sinnvoll miteinander kombinieren lassen. [4] [13]

Das reduziert die Komplexität. Entwickler müssen weniger Zusammenhänge gleichzeitig überblicken und können Änderungen gezielter umsetzen. Dasselbe Prinzip hilft KI-Systemen: Je klarer eine Aufgabe eingegrenzt ist, desto weniger Kontext muss das Modell berücksichtigen.

Dag Dammann beschreibt diesen Zusammenhang über die sogenannte kognitive Last. Während Menschen nur eine begrenzte Menge an Informationen gleichzeitig sinnvoll verarbeiten können, arbeiten KI-Modelle innerhalb eines begrenzten Kontextfensters. Große, unübersichtliche Systeme erschweren deshalb sowohl die menschliche Arbeit als auch die gezielte Nutzung von KI.

Die Studie »Lost in the Middle« liefert eine begrenzte empirische Einordnung zur Kontextnutzung: In den untersuchten Frage-Antwort- und Abrufaufgaben beobachteten die Autoren Leistungsunterschiede je nach Position relevanter Informationen. Die daraus abgeleitete Empfehlung, Kontext gezielt auszuwählen, basiert auf diesen beobachteten Mustern. Die 2024 veröffentlichte Untersuchung belegt weder die Leistungsfähigkeit jedes heutigen Modells noch unmittelbar einen Vorteil modularer Softwarearchitektur beim Programmieren. [18]

Cloud-Native-Architekturen und Microservices können dabei helfen, Verantwortlichkeiten und Schnittstellen klar zu definieren. Sie sind kein Selbstzweck, schaffen aber eine Grundlage, auf der Anwendungen modular entwickelt, betrieben und erweitert werden können. [4] [9] [13]

Auch die Architektur selbst sollte dabei nicht vollständig an die KI delegiert werden. Dammann setzt bewusst zuerst die Struktur: Er legt fest, welche Komponenten benötigt werden, wie sie kommunizieren und welche Sprachen oder Frameworks zum Einsatz kommen. Anschließend kann KI bei der konkreten Implementierung unterstützen – innerhalb nachvollziehbarer Leitplanken.

»Die gebaute Software muss so übersichtlich sein, dass sie irgendwann noch einmal verstanden wird.«
Dag Dammann, Senior IT Consultant bei accompio

Cloud Native, Platform Engineering und Standards als Beschleuniger

Cloud-Native-Ansätze helfen dabei, Anwendungen so aufzubauen, dass sie standardisierte Cloud-Plattformen und Orchestrierungslösungen nutzen können. Container und Plattformen wie Kubernetes stellen dafür etablierte Mechanismen bereit, die Unternehmen nicht für jede Anwendung neu entwickeln müssen. [9] [10]

Platform Engineering baut auf diesem Gedanken auf: Teams erhalten standardisierte Plattformen und wiederverwendbare Abläufe, um Anwendungen effizienter bereitzustellen und zu betreiben. Automatisierung, Sicherheitsprüfungen und Monitoring lassen sich dadurch besser in bestehende Prozesse integrieren. [3] [16]

Auch Standards wie Containerisierung und GitOps schaffen wiederholbare Abläufe. [11] [12] Das verursacht zunächst Aufwand, erleichtert später jedoch den Betrieb und die Zusammenarbeit. Neue Mitarbeitende finden sich schneller zurecht, wenn sie bekannte Konzepte wiedererkennen. Für KI gilt etwas Ähnliches: Gängige Technologien und etablierte Standards sind in vielen Modellen bereits gut repräsentiert. Sie müssen daher weniger individuelle Sonderlösungen erklären und können auf bekanntem Wissen aufbauen.

Der Vorteil liegt also nicht allein in der Technologie. Standards schaffen gemeinsame Schnittstellen, reduzieren unnötige Komplexität und erleichtern es, Entwicklung, Sicherheit und Betrieb miteinander zu verbinden.

Warum Entwickler künftig den gesamten Prozess verstehen müssen

Mit zunehmender KI-Unterstützung wird es wichtiger, nicht nur einzelne Programmierschritte zu beherrschen. Gefragt sind laut Dammann verstärkt sogenannte T-Shaped Developer: Fachkräfte mit breitem Wissen über den gesamten Software-Lebenszyklus und zusätzlicher Tiefe in einem bestimmten Bereich.

Das NIST SSDF empfiehlt, sichere Entwicklungspraktiken in den jeweiligen Softwareentwicklungszyklus zu integrieren, statt ein einheitliches Phasenmodell vorzugeben. [2] DORA empfiehlt kontinuierliche Tests während des gesamten Lieferprozesses. [14] Für den laufenden Betrieb beschreibt das Google-SRE-Kapitel Monitoring und Alarmierung. [16] Daraus ergibt sich die redaktionelle Empfehlung, Sicherheitsanforderungen, Tests und Betriebsrückmeldungen bei der Bewertung einer Änderung gemeinsam zu berücksichtigen.

Für die Arbeit mit KI-gestützten Entwicklungstools empfiehlt sich deshalb, projektspezifische Anforderungen ausdrücklich festzuhalten und Ergebnisse auf ihre fachliche Eignung zu prüfen. Die konkrete GitHub-Dokumentation zu benutzerdefinierten Code-Review-Anweisungen empfiehlt klare, präzise Vorgaben und die Berücksichtigung der jeweiligen Projektstandards. [17] DORA empfiehlt außerdem kontinuierliche Tests zur Prüfung von Funktionalität und Architektur. [14] Daraus folgt die redaktionelle Empfehlung, technische Entscheidungen und Fehler anhand nachvollziehbarer Anforderungen zu beurteilen, statt sich ausschließlich auf ein erzeugtes Ergebnis zu verlassen.

KI verschiebt damit einen Teil der Arbeit: Weniger Zeit muss möglicherweise in die manuelle Umsetzung einzelner Codeabschnitte fließen. Dafür gewinnen Architekturverständnis, Problemanalyse, Prozesswissen und die Bewertung technischer Lösungen an Bedeutung.

Erst Prozesse verstehen, dann mit KI beschleunigen

Bevor Unternehmen KI-gestützte Softwareentwicklung skalieren, sollten sie ihre bestehenden Prozesse überprüfen und dokumentieren. Sind Abläufe unklar oder widersprüchlich, kann Automatisierung die zugrunde liegenden Probleme sogar schneller und in größerem Umfang reproduzieren. [1] [20]

Ein häufiger Fehler besteht darin, direkt mit dem größten und schwierigsten Problem zu starten. Scheitert das Vorhaben, entstehen nicht nur Kosten, sondern möglicherweise auch Vorbehalte gegenüber der neuen Technologie.

Dammanns Empfehlung lautet deshalb, mit einer klaren Zielvorstellung zu starten und zunächst einen überschaubaren Anwendungsfall auszuwählen. Dieser muss nicht das größte Problem im Unternehmen lösen. Wichtig ist, dass sich der Ansatz in einem begrenzten Rahmen testen und bewerten lässt.

So können Teams Erfahrungen sammeln, technische und organisatorische Herausforderungen erkennen und den Einsatz anschließend schrittweise ausweiten. KI wird damit nicht als isoliertes Werkzeug eingeführt, sondern als Bestandteil eines durchdachten Entwicklungsprozesses.

Fazit: Erst das Fundament, dann die Geschwindigkeit

KI bietet Unternehmen die Chance, Software schneller zu entwickeln und bestehende Prozesse neu zu gestalten. Nachhaltig wird dieser Vorteil jedoch erst, wenn Architektur, Standards und Betriebsprozesse mitwachsen.

Modulare Systeme, Cloud-Native-Technologien und standardisierte Abläufe schaffen die Grundlage dafür, dass KI-generierter Code verständlich und wartbar bleibt. Gleichzeitig brauchen Entwicklungsteams Mitarbeitende, die den gesamten Software-Lebenszyklus verstehen, klare Vorgaben machen und Ergebnisse fachlich beurteilen können.

Dag Dammanns zentrale Empfehlung: Unternehmen sollten die technischen Grundlagen beherrschen, Prozesse transparent machen und mit kleinen, kontrollierbaren Schritten beginnen. Denn Geschwindigkeit allein bringt wenig, wenn die Richtung nicht stimmt.

»Wenn man etwas nicht langsam kann, dann kann man es in der Regel auch nicht schnell.«
Dag Dammann, Senior IT Consultant bei accompio

Über den Experten

Dag Dammann, Senior IT Consultant bei accompio

Dag unterstützt Unternehmen bei der Integration von KI in der Softwareentwicklung, damit Lösungen nicht nur schneller entstehen, sondern auch langfristig betrieben und weiterentwickelt werden können.

Praxisergänzungen: Tipps, FAQ und Quellen

Tipps für CIOs und Entwicklungsteams

Die folgenden Tipps sind redaktionelle Handlungsempfehlungen auf Grundlage der genannten Quellen, keine Zusagen für bestimmte Produktivitäts- oder Sicherheitsgewinne.

Den Engpass vor der Tool-Auswahl klären. Erfassen Sie Wartezeiten zwischen Entwicklung, Review, Test und Bereitstellung. Definieren Sie, welchen konkreten Schritt der KI-Pilot verbessern soll. Prüfen Sie das Ergebnis anhand von Durchlaufzeit und Lieferstabilität, nicht anhand erzeugter Codezeilen. [15] [20]
Architekturleitplanken schriftlich festhalten. Dokumentieren Sie Modulaufgaben, Schnittstellen, zulässige Abhängigkeiten und Betriebsanforderungen. Entscheiden Sie ausdrücklich, ob unabhängige Dienste erforderlich sind oder eine weniger verteilte Architektur ausreicht. [4] [8] [13]
Qualitätsprüfungen zum festen Lieferbestandteil machen. Verknüpfen Sie Änderungen mit fachlichem Review, automatisierten Tests und risikogerechten Sicherheitsprüfungen. Legen Sie fest, wer bei nicht erfüllten Kriterien über die Freigabe entscheidet. [2] [14] [17]
Die Plattform vom Nutzerbedarf her entwickeln. Beginnen Sie mit häufig wiederkehrenden Aufgaben wie Projektstart, Build, Test oder Deployment. Holen Sie Feedback der Anwendungsteams ein, bevor Sie weitere Plattformfunktionen ausbauen. [3]
Zugriffe und Schutzbedarf prüfen. Klären Sie vor dem Pilot, welche Quelltexte und Daten ein Werkzeug verarbeiten darf und welche Zugriffsrechte erforderlich sind. Beziehen Sie Informationssicherheit und die zuständigen Datenschutzverantwortlichen in die konkrete Werkzeugprüfung ein. [2] [19]
Den Pilot mit einer Ausgangsmessung starten. Vergleichen Sie einen begrenzten Anwendungsfall vor und während des KI-Einsatzes. Erfassen Sie auch Review-Aufwand und Nacharbeit; bewerten Sie Veränderungen im Zusammenhang mit Aufgabenart und Prozessänderungen. [6] [15]
Skalierung an nachgewiesenen Bedarf knüpfen. Vereinbaren Sie Entscheidungskriterien für Ausbau, Anpassung oder Abbruch. Das CNCF-Reifegradmodell betont, dass ein höherer Reifegrad zusätzliche Ressourcen erfordert und kein Selbstzweck ist. [5]

Infografik: Die sieben Tipps im vollständigen Wortlaut einschließlich Quellenbezugszeichen. KI-generierte Illustration.

Ausführliche Tipps mit Praxisbeispielen

Die folgenden Umsetzungsschritte sind redaktionelle Empfehlungen zu den sieben vorhandenen Tipps. Alle Praxisbeispiele sind fiktive Szenarien, keine dokumentierten Unternehmensfälle und keine Nachweise für erzielte Verbesserungen. Die Bezugszeichen verweisen auf die fachlichen Grundlagen im bestehenden Quellenverzeichnis; sie belegen nicht die fiktiven Beispiele. Konkrete Zielwerte und Pilotzeiträume sind anhand des eigenen Ausgangszustands festzulegen.

1. Den Engpass vor der Tool-Auswahl klären

Umsetzung: Zeichnen Sie den Weg einer Änderung von der Anforderung bis zur Bereitstellung auf. Unterscheiden Sie aktive Bearbeitung von Wartezeit und erfassen Sie Übergaben, Rückfragen sowie wiederholte Prüfungen. Wählen Sie einen klar abgegrenzten Engpass und formulieren Sie eine überprüfbare Pilotfrage, etwa: Verkürzt die Unterstützung bei der Erstellung von Testentwürfen die Zeit bis zur prüfbaren Änderung? Wertstromanalyse und Liefermetriken bilden die fachliche Grundlage dieser Empfehlung. [15] [20]

Fiktives Praxisbeispiel: Bei einem Anbieter von Geschäftssoftware warten Änderungen regelmäßig auf eine verfügbare Testumgebung. Das Team dokumentiert die Wartephasen und entscheidet zunächst, die Bereitstellung der Umgebung zu vereinfachen. Ein KI-Werkzeug für Programmcode wird nicht allein deshalb eingeführt, weil es verfügbar ist. Ein späterer Pilot für Testentwürfe erhält eine eigene Fragestellung.

Prüfkriterien: Liegt eine Prozessskizze mit eindeutigen Start- und Endpunkten vor? Sind Wartezeiten getrennt erfasst? Ist der ausgewählte Engpass benannt und einer verantwortlichen Stelle zugeordnet? Vergleichen Sie Durchlaufzeit und Lieferstabilität; eine bloße Zunahme erzeugter Codezeilen reicht als Erfolgskriterium nicht aus.

2. Architekturleitplanken schriftlich festhalten

Umsetzung: Erstellen Sie eine kompakte Architekturübersicht mit Modulaufgaben, erlaubten Abhängigkeiten, Schnittstellen und Datenverantwortung. Dokumentieren Sie außerdem Anforderungen an Fehlermeldungen, Betrieb und Kompatibilität. Halten Sie wichtige Entscheidungen samt Gründen fest. Prüfen Sie, ob unabhängige Bereitstellung tatsächlich benötigt wird oder ein modularer Monolith genügt. Die Abwägung zwischen klaren Grenzen und den Kosten verteilter Systeme stützt sich auf Fowler und DORA. [4] [8] [13]

Fiktives Praxisbeispiel: Ein Bestellportal erhält eine neue Rabattfunktion. Das Team legt fest, dass die Preisberechnung in einem eigenen Modul erfolgt und der Bestellablauf nur dessen dokumentierte Schnittstelle verwendet. Direkte Zugriffe auf interne Preisregeln sind ausgeschlossen. Die Änderung bleibt zunächst innerhalb einer Anwendung; eine Aufteilung in eigenständige Dienste wird erst bei einem konkret begründeten Bedarf geprüft.

Prüfkriterien: Sind Schnittstellen und Verantwortlichkeiten nachvollziehbar dokumentiert? Kann eine Änderung ohne undokumentierte Zugriffe auf fremde Module umgesetzt werden? Sind Vertrags- beziehungsweise Schnittstellentests vorgesehen? Jede zusätzliche Dienstgrenze sollte eine benannte Anforderung erfüllen, statt nur einem Architekturtrend zu folgen.

3. Qualitätsprüfungen zum festen Lieferbestandteil machen

Umsetzung: Definieren Sie Freigabekriterien vor Beginn des Pilots: fachliche Akzeptanzbedingungen, erforderliche Tests, Sicherheitsprüfungen und dokumentierte Review-Entscheidungen. Verknüpfen Sie Prüfungen mit der Bereitstellungspipeline und regeln Sie den Umgang mit Ausnahmen. Projektspezifische Review-Anweisungen ergänzen die Prüfung, ersetzen aber keine eindeutigen Freigabekriterien. Die Grundlagen liefern NIST SSDF, DORAs Testleitfaden und die konkrete GitHub-Dokumentation. [2] [14] [17]

Fiktives Praxisbeispiel: Ein Team ergänzt eine Exportfunktion. Vor der Freigabe müssen Tests für leere Ergebnisse, unterschiedliche Berechtigungen und fehlerhafte Eingaben bestehen. Eine fachliche Prüfung kontrolliert das Ausgabeformat; eine Sicherheitsprüfung betrachtet den Zugriff auf geschützte Datensätze. Eine Änderung mit offenen Pflichtprüfungen wird zur Nacharbeit zurückgegeben, nicht allein aufgrund eines plausibel wirkenden Ergebnisses freigegeben.

Prüfkriterien: Sind Pflichtprüfungen eindeutig benannt und deren Ergebnisse einsehbar? Ist die fachliche Freigabe dokumentiert? Gibt es für Ausnahmen eine zuständige Stelle, Begründung und Wiedervorlage? Erfassen Sie wiederkehrende Testfehler und Nacharbeit, ohne aus einzelnen Messwerten vorschnell einen allgemeinen Produktivitätsgewinn abzuleiten.

4. Die Plattform vom Nutzerbedarf her entwickeln

Umsetzung: Erheben Sie wiederkehrende Aufgaben und Hindernisse der Anwendungsteams. Wählen Sie zunächst einen häufig benötigten Ablauf, etwa Projektstart oder Testbereitstellung, und entwickeln Sie dafür einen dokumentierten Standardweg. Legen Sie Zuständigkeiten, Unterstützung und Rückmeldemöglichkeiten fest. Priorisieren Sie weitere Funktionen anhand der Nutzung und des konkreten Bedarfs. Diese Empfehlung folgt dem CNCF-Verständnis einer Plattform als internem Produkt. [3]

Fiktives Praxisbeispiel: Mehrere Teams richten für neue Schnittstellenprojekte ähnliche Build- und Testabläufe ein. Das Plattformteam entwickelt eine gemeinsame Projektvorlage mit dokumentierten Einstiegsschritten und einem standardisierten Testprozess. Zwei Anwendungsteams erproben den Ablauf und melden fehlende Konfigurationsmöglichkeiten zurück. Erst nach dieser Rückmeldung wird der Funktionsumfang erweitert.

Prüfkriterien: Kann ein Team den Standardweg mit der vorhandenen Dokumentation nutzen? Welche manuellen Schritte bleiben? Werden dieselben Unterstützungsfragen wiederholt gestellt? Betrachten Sie Nutzung, Einstiegshürden und Rückmeldungen gemeinsam; die Anzahl bereitgestellter Plattformfunktionen allein sagt wenig über ihren Nutzen aus.

5. Zugriffe und Schutzbedarf prüfen

Umsetzung: Dokumentieren Sie, welche Inhalte verarbeitet werden sollen, wohin Daten übertragen werden und welche Zugriffe benötigt werden. Prüfen Sie Vertragsbedingungen, Produkteinstellungen, Aufbewahrung und mögliche Trainingsnutzung anhand der konkreten Unterlagen. Legen Sie zugelassene Einsatzfälle und untersagte Inhalte fest. Lassen Sie offene Punkte durch Informationssicherheit und Datenschutz klären. NIST SSDF und AI RMF liefern Orientierungsrahmen, keine pauschale Freigabe eines bestimmten Werkzeugs. [2] [19]

Fiktives Praxisbeispiel: Für einen Pilot wird zunächst ein separates Repository mit synthetischen Beispieldaten eingerichtet. Produktive Kundendaten und Zugangsschlüssel sind nicht Bestandteil dieses Einsatzfalls. Das Team dokumentiert die zugelassenen Zugriffe und prüft die Vertrags- und Produkteinstellungen vor einer möglichen Erweiterung. Nicht geklärte Datenverarbeitung bleibt ein offener Freigabepunkt.

Prüfkriterien: Liegen eine Datenflussübersicht und eine dokumentierte Werkzeugentscheidung vor? Sind Berechtigungen auf den genehmigten Einsatzfall begrenzt? Sind Vertragsversion und Einstellungen nachvollziehbar festgehalten? Nach relevanten Produkt- oder Vertragsänderungen sollte die Entscheidung erneut geprüft werden.

6. Den Pilot mit einer Ausgangsmessung starten

Umsetzung: Legen Sie Start- und Endpunkte der Messung fest und erfassen Sie vergleichbare Aufgaben zunächst ohne die neue Unterstützung. Dokumentieren Sie Aufgabenart, Umfang, Wartezeit, Review-Aufwand und Nacharbeit auch während des Pilots. Halten Sie parallele Prozessänderungen fest. Betrachten Sie Durchsatz und Stabilität gemeinsam; ein Vorher-nachher-Vergleich allein weist keinen ursächlichen Werkzeugeffekt nach. Die Empfehlung knüpft an die DORA-Ergebnisdarstellung und die Liefermetriken an. [6] [15]

Fiktives Praxisbeispiel: Ein Team erprobt Unterstützung bei wiederkehrenden Änderungen an Validierungsregeln. Die Ausgangsmessung und der Pilot unterscheiden kleine Anpassungen von größeren fachlichen Erweiterungen. Wird während des Pilots auch die Testpipeline umgebaut, hält das Team diese Änderung gesondert fest. Die Auswertung beschreibt Unterschiede und verbleibende Unsicherheit, statt jede Verbesserung automatisch dem Werkzeug zuzuschreiben.

Prüfkriterien: Sind die verglichenen Aufgaben ausreichend ähnlich? Wurden fehlgeschlagene oder abgebrochene Versuche ebenfalls erfasst? Ist Nacharbeit Bestandteil der Betrachtung? Dokumentieren Sie Fallzahl, Messgrenzen und Änderungen der Rahmenbedingungen; legen Sie keine allgemeingültigen Zielwerte ohne eigenen Ausgangsbefund fest.

7. Skalierung an nachgewiesenen Bedarf knüpfen

Umsetzung: Vereinbaren Sie vor der Ausweitung Kriterien für Ausbau, Anpassung oder Abbruch. Dazu gehören ein dokumentierter Nutzen, akzeptable Qualitäts- und Sicherheitsbefunde, geklärte Betriebskosten und verfügbare Unterstützung. Erweitern Sie den Einsatzfall schrittweise und prüfen Sie nach jeder Erweiterung die ursprünglichen Annahmen. Das CNCF-Reifegradmodell betont, dass höhere Reifegrade Ressourcen erfordern und kein Selbstzweck sind. [5]

Fiktives Praxisbeispiel: Nach einem begrenzten Pilot für interne Verwaltungsfunktionen prüft ein Unternehmen die Ausweitung auf ein weiteres Repository. Vorher werden dessen Schutzbedarf, Testabdeckung, Zuständigkeiten und Unterstützungsaufwand gesondert bewertet. Ein Bereich mit ungeklärten Freigabekriterien bleibt zunächst außerhalb des Rollouts. Die Entscheidung orientiert sich am jeweiligen Einsatzfall, nicht an einem pauschalen Einführungsziel.

Prüfkriterien: Sind erwarteter Nutzen, laufende Kosten und Unterstützungsbedarf dokumentiert? Gibt es eine zuständige Stelle für erneute Bewertung und Beendigung des Einsatzes? Sind Qualitäts- und Schutzanforderungen für den erweiterten Bereich erfüllt? Ein begründetes Nicht-Skalieren ist ebenfalls ein zulässiges Ergebnis des Pilots.

FAQ: Zehn Fragen zur KI-gestützten Softwareentwicklung

1. Bedeutet KI-Einsatz automatisch höhere Produktivität?

Der DORA-Report 2025 beschreibt KI als Verstärker vorhandener organisatorischer Fähigkeiten und Schwächen. [1] Die begleitende Ergebnisdarstellung berichtet positive Zusammenhänge mit Lieferdurchsatz und Produktleistung, zugleich aber einen negativen Zusammenhang mit Lieferstabilität. [6] Das ist kein Nachweis eines garantierten Effekts in jedem Unternehmen und keine individuelle Produktivitätsprognose.

2. Warum bleibt Softwarearchitektur wichtig?

DORA hebt lose gekoppelte Architekturen und schnelle Rückmeldeschleifen als relevante Bedingungen im Umfeld KI-gestützter Entwicklung hervor. [6] [13] Klare Modulgrenzen sind außerdem ein zentrales Architekturprinzip in Fowlers Darstellung von Microservices. [4] Die redaktionelle Konsequenz lautet: Architekturentscheidungen, Schnittstellen und Zuständigkeiten vor einer breiten Skalierung explizit festhalten.

3. Sind Microservices für KI-gestützte Entwicklung erforderlich?

Aus den genannten Quellen lässt sich keine solche Pflicht ableiten. Fowler beschreibt Microservices als Architektur mit Vorteilen wie unabhängiger Bereitstellung, aber auch mit Kosten verteilter Kommunikation und zusätzlicher Komplexität. [4] Sein Beitrag »Monolith First« argumentiert für einen zunächst monolithischen Ansatz bei neuen Anwendungen. [8] Diese Architekturbeiträge stammen aus 2015 beziehungsweise 2019 und sind keine aktuellen Studien zum KI-Einsatz.

4. Was leistet Platform Engineering?

Der CNCF-Leitfaden beschreibt interne Plattformen als gebündelte Fähigkeiten und Nutzungserfahrungen für interne Kunden, etwa Anwendungsteams. Dazu zählen wiederverwendbare Dienste für Infrastruktur, Builds, Tests, Bereitstellung und Beobachtbarkeit. Ziel ist unter anderem, doppelte Arbeit und die Belastung der Produktteams durch Infrastrukturaufgaben zu reduzieren. Eine Plattform sollte deshalb als internes Produkt entwickelt werden, nicht nur als Sammlung von Werkzeugen. [3]

5. Welche Qualitätskontrollen sollten erhalten bleiben?

DORA nennt robuste automatisierte Tests, ausgereifte Versionskontrolle und schnelle Rückmeldeschleifen als wichtige Kontrollmechanismen. [6] [14] Das NIST SSDF empfiehlt, Sicherheitspraktiken in den Softwareentwicklungszyklus zu integrieren. [2] Für die Praxis empfiehlt sich, Freigabekriterien an den Risiken und Anforderungen der Anwendung auszurichten und KI-Unterstützung nicht als Anlass für schwächere Prüfungen zu behandeln.

6. Wie lässt sich der Nutzen sinnvoll messen?

Aus der DORA-Ergebnisdarstellung folgt die Empfehlung, Durchsatz und Stabilität gemeinsam zu betrachten. Ergänzend sollten Unternehmen einen konkreten fachlichen Nutzen definieren, etwa die kürzere Bereitstellung einer benötigten Funktion. Für einen Pilot bieten sich Ausgangsmessung, Durchlaufzeit, fehlerbedingte Nacharbeit und Review-Aufwand an. Ein Vorher-nachher-Vergleich allein belegt allerdings nicht, dass sämtliche Veränderungen durch das KI-Werkzeug verursacht wurden. [6] [15] [20]

7. Wie sollte ein Unternehmen mit dem Pilot beginnen?

Empfehlenswert ist ein abgegrenzter Anwendungsfall mit nachvollziehbarem Nutzerbedarf, dokumentierten Abläufen und überprüfbaren Qualitätsanforderungen. Vereinbaren Sie vorab Erfolgskriterien und eine verantwortliche Freigabeinstanz. Diese Handlungsempfehlung verbindet den von DORA betonten Fokus auf das organisatorische System mit der Nutzerorientierung des CNCF-Plattformleitfadens; sie ist kein universeller Einführungsplan. [1] [3] [20]

8. Welche Rolle spielt der Schutz von Quelltext und Daten?

Das NIST SSDF umfasst den Schutz von Softwarekomponenten vor Manipulation und unberechtigtem Zugriff sowie die organisatorische Vorbereitung sicherer Entwicklung. [2] Für die konkrete Werkzeugauswahl sollten Unternehmen deshalb Datenflüsse, Zugriffsrechte und den Schutzbedarf ihrer Inhalte prüfen. Prüfen Sie zusätzlich die konkreten Vertragsbedingungen und Produkteinstellungen zu Speicherung und Trainingsnutzung, bevor Sie Quelltexte oder vertrauliche Daten freigeben.

Als ergänzende Orientierung für die Bewertung des KI-Einsatzes beschreibt das NIST AI Risk Management Framework einen freiwilligen Rahmen für die Gestaltung, Entwicklung, Nutzung und Evaluation von KI-Systemen. Seine Anwendung ersetzt nicht die Prüfung konkreter Verträge, Datenflüsse und Schutzanforderungen. [19]

9. Müssen Unternehmen den höchsten Plattformreifegrad erreichen?

Nein. Das CNCF-Reifegradmodell betont ausdrücklich, dass höhere Reifegrade mehr Finanzierung und Arbeitszeit erfordern und nicht zum Selbstzweck werden sollten. Organisationen sollen prüfen, welche Fähigkeiten im jeweiligen Kontext den Investitionsaufwand rechtfertigen. Für Entscheider lautet die Empfehlung daher: gezielt Engpässe adressieren, statt möglichst viele Plattformfunktionen aufzubauen. [5]

10. Wie belastbar sind die verwendeten Quellen?

DORA 2025 stützt sich laut Google Research auf Befragungsantworten von knapp 5.000 Technologie-Fachkräften und mehr als 100 Stunden qualitativer Forschung. [7] Die Ergebnisse sind nicht mit einem kontrollierten Wirksamkeitsnachweis für jedes Unternehmen gleichzusetzen. [1] [7] Das NIST SSDF ist ein Empfehlungsrahmen; die CNCF-Veröffentlichungen sind praxisorientierte Community-Leitfäden, und Fowlers Beiträge sind fachliche Architekturargumentationen. [2] [3] [4] [5] [8] Die unterschiedlichen Quellentypen sollten bei der Interpretation berücksichtigt werden.

Quellen

Recherche: 31. Oktober 2026. Jede Nummer bezeichnet eine einzelne Quelle mit einer URL; Bezugszeichen stehen unmittelbar bei den zugeordneten Aussagen oder Handlungsempfehlungen. Forschungsbericht und zugehörige Ergebnis- beziehungsweise Methodenübersichten [1], [6] und [7] sind keine unabhängigen Studien. Technische Dokumentationen, Empfehlungsrahmen und Fachbeiträge sind als solche gekennzeichnet. Personenbezogene Angaben und wörtliche Interviewzitate bleiben dem ursprünglichen Interview zugeordnet; die zusätzliche Recherche verifiziert sie nicht.

[1] DORA: State of AI-assisted Software Development 2025. Forschungsbericht, 2025. https://dora.dev/research/2025/dora-report/

[2] NIST: Secure Software Development Framework (SSDF), Version 1.1, SP 800-218. Empfehlungsrahmen, Februar 2022. https://csrc.nist.gov/pubs/sp/800/218/final

[3] CNCF TAG App Delivery: CNCF Platforms White Paper. Praxisleitfaden. https://tag-app-delivery.cncf.io/whitepapers/platforms/

[4] Martin Fowler: Microservices Guide. Architekturleitfaden, 21. August 2019. https://martinfowler.com/microservices/

[5] CNCF TAG App Delivery: Platform Engineering Maturity Model. Reifegradmodell. https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/

[6] Google Cloud, Nathen Harvey und Derek DeBellis: Announcing the 2025 DORA Report: State of AI-Assisted Software Development. Ergebnisdarstellung, 23. September 2025. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report

[7] Google Research, Derek DeBellis et al.: DORA 2025 State of AI-assisted Software Development Report. Publikations- und Methodenüberblick, 2025. https://research.google/pubs/dora-2025-state-of-ai-assisted-software-development-report/

[8] Martin Fowler: Monolith First. Fachbeitrag, 3. Juni 2015. https://martinfowler.com/bliki/MonolithFirst.html

[9] CNCF Technical Oversight Committee: Cloud Native Definition v1.1. Definition, verabschiedet am 26. Februar 2024. https://github.com/cncf/toc/blob/main/DEFINITION.md

[10] Kubernetes: Overview. Technische Dokumentation. https://kubernetes.io/docs/concepts/overview/

[11] Open Container Initiative: About the Open Container Initiative. Überblick zu Containerstandards. https://opencontainers.org/about/overview/

[12] OpenGitOps: GitOps Principles v1.0.0. Prinzipien und Standards. https://opengitops.dev/

[13] DORA: Capabilities – Loosely coupled teams. Architektur- und Organisationsleitfaden. https://dora.dev/capabilities/loosely-coupled-teams/

[14] DORA: Capabilities – Test automation. Praxisleitfaden. https://dora.dev/capabilities/test-automation/

[15] DORA, Nathen Harvey: DORA’s software delivery performance metrics. Messleitfaden. https://dora.dev/guides/dora-metrics/

[16] Google SRE, Rob Ewaschuk: Monitoring Distributed Systems. Fachkapitel, 2016. https://sre.google/sre-book/monitoring-distributed-systems/

[17] GitHub Docs: Using custom instructions to unlock the power of Copilot code review. Konkrete Herstellerdokumentation zu klaren Prüfanweisungen, Projektstandards und Grenzen ihrer Umsetzung. https://docs.github.com/en/copilot/tutorials/customize-code-review

[18] Nelson F. Liu et al.: Lost in the Middle: How Language Models Use Long Contexts. TACL, Band 12, Seiten 157–173, 2024; Experimente mit damaligen Modellen, kein Nachweis für jedes heutige Modell. https://aclanthology.org/2024.tacl-1.9/

[19] NIST: AI Risk Management Framework. Freiwilliger Risikomanagementrahmen; Version 1.0 veröffentlicht am 26. Januar 2023. https://www.nist.gov/itl/ai-risk-management-framework

[20] DORA, Andrew Davis und Rob Edwards: How to use value stream mapping to improve software delivery. Prozessleitfaden. https://dora.dev/guides/value-stream-management/

Management Summary, Tipps, FAQ und Bilder wurden mit Hilfe von KI erstellt

1250 Artikel zu „KI Softwareentwicklung“

Business Process Management | Digitalisierung | Künstliche Intelligenz | New Work | News | Services | Tipps | Trends 2026 | Trends Services

Mehr Code, mehr Reibung: Warum KI allein die Softwareentwicklung nicht beschleunigt

22. Oktober 2026

KI lässt Entwicklerinnen und Entwickler schneller Code produzieren – doch sie beschleunigt nicht automatisch die gesamte Softwarelieferung. Die Atlassian-Studie »State of Developer Experience 2026« zeigt: Organisatorische Engpässe, aufwendige Reviews, technische Schulden und fehlende Strategien zehren viele lokale Zeitgewinne wieder auf. Für CIOs und Entwicklungsleitungen kommt es deshalb weniger auf die Zahl eingesetzter Tools an als…