Wenn KI entwickelt & die neue Entwickler:innen-Rolle: Leitartikel

Von Vorurteil und Paradox zum Narrativ

Wir haben einige der vielen Aussagen rund um KI in der Softwareentwicklung für uns eingeordnet:

• Kann jetzt jede:r entwickeln?

• Wird Programmieren überflüssig?

• Und führt KI automatisch zu mehr Effizienz?

Besonders relevant für uns, da sich nicht nur unsere Arbeitsweise, sondern auch unser Geschäftsmodell verändert. Die wichtigsten Ergebnisse vorab:

Ein Teil unseres Teams nutzt GitHub Copilot, einen KI-Agenten, der bei der Softwareentwicklung unterstützt, bereits aktiv und sammelt erste Erfahrungen im Alltag. Nun weiten wir den Einsatz auf alle Entwickler:innen aus und begleiten diesen Schritt:

Wir wollten wir verstehen, was sich tatsächlich verändert und was nur als Narrativ im Raum steht, denn zwischen Hype, Skepsis und widersprüchlichen Erfahrungen entstehen oft (Vor-)Urteile, die sich festsetzen und Orientierung suggerieren. Aber was davon trifft zu?

Wir sind ein kleines Team von rund 20 Entwickler:innen und haben die gängigsten Thesen bewusst auf unsere eigene Arbeitsweise übertragen und auf die Probe gestellt, um daraus ein eigenes Bild abzuleiten. Nicht als allgemeingültige Wahrheit, sondern als Arbeitsgrundlage für uns. Unser Ziel ist es, ein für uns konsistentes Narrativ zu entwickeln, das uns hilft, bessere Entscheidungen im Umgang mit KI zu treffen insbesondere mit Blick auf den breiteren Rollout im Team.

Viele der folgenden Thesen werden bekannt vorkommen. Sie prägen aktuell die Diskussion und wirken oft intuitiv richtig. Genau deshalb lohnt es sich, genauer hinzuschauen. Auch wenn sich nicht alles aus unserer kleinen Nutzergruppe heraus generalisieren lässt, lohnt sich der Blick und Übertrag für alle Organisationen.

Zur Methodik

Über die GitHub Copilot Usage Schnittstelle lassen sich Telemetrie-Daten zur tatsächlichen Nutzung von Copilot als KI-Agent in der Softwareentwicklung gewinnen. Dazu gehören unter anderem Interaktionen, genutzte Features, zeitliche Nutzungsmuster sowie Kontextinformationen auf Nutzerebene.

Auf dieser Grundlage haben wir eigene, vereinfachte Kennzahlen abgeleitet, die uns helfen, Nutzung und Verhalten im Kontext der folgenden Thesen besser einzuordnen. Wichtig ist dabei: Diese Metriken messen nicht direkt Qualität, Kompetenz oder Vertrauen, sondern dienen als Proxy für beobachtbares Verhalten und Adoption.

Dafür haben wir unsere Entwickler:innen den Rollen Junior bis Senior zugeordnet und vergleichen die Thesen im Folgenden auf diesem Aggregationslevel.

Thesen auf der Probe

Wir haben drei der aktuell häufig zitierten Aussagen zu KI in der Softwareentwicklung genauer untersucht. Viele dieser Aussagen drehen sich um die zentrale Frage, ob KI die Softwareentwicklung so grundlegend verändert, dass klassische Rollen an Bedeutung verlieren. Die zunehmende „Demokratisierung“ in der Programmierung durch natürliche Sprache legt genau das nahe:

Die Software-Entwicklung wird zugänglicher, schneller und weniger abhängig von tiefem technischem Wissen.

Um das besser zu verstehen, haben wir unsere eigenen Nutzungsdaten und Erfahrungen den gängigen Thesen gegenübergestellt. Für jede These stellen wir eine eigene Auswertung vor. Zunächst betrachten wir die Auswertungen einzeln, ordnen sie dann aber auch gemeinschaftlich ein, da sich die Ergebnisse teilweise gegenseitig stützen.

Zur Überprüfung der These haben wir ausgewertet, wie unsere Entwickler:innen KI-generierten Code in der täglichen Arbeit übernehmen. In der Auswertung haben wir die Anzahl der generierten Codezeilen (Lines of Code, LOC) über den Zeitverlauf betrachtet. Dabei unterscheiden wir zwei zentrale Metriken.

• Effective LOC: das Verhältnis von erzeugten Codezeilen pro Generierung, also beispielsweise pro Prompt

• Total LOC: die Gesamtanzahl der erzeugten Codezeilen

Beide Werte sind sowohl über die Zeit als auch als durchschnittliche Tageswerte dargestellt.

Die Auswertung zeigt, dass Senior-Entwickler:innen im Tagesdurchschnitt deutlich mehr Code über KI-Agenten erzeugen als Junior-Entwickler:innen (382 vs. 199 LOC). Gleichzeitig liegen Juniors bei den Effective LOCs über den Seniors: Pro Generierung entstehen also im Schnitt größere Codeblöcke.

Das deutet auf unterschiedliche Arbeitsweisen hin:

• Senior-Entwickler:innen arbeiten kleinteiliger und iterativer: Sie erzeugen insgesamt mehr Code, verteilen diesen aber auf mehr, kleinere Generierungen.

• Junior-Entwickler:innen hingegen erzeugen pro Prompt größere Einheiten. Das kann darauf hindeuten, dass sie versuchen, mehr Aufgaben in einer einzelnen Generierung zu bündeln.

Setzt man dies jedoch ins Verhältnis zum insgesamt geringeren Codevolumen, ergibt sich ein anderes Bild: Junior-Entwickler:innen nutzen den Agenten insgesamt seltener und gezielter. Die größeren Codeblöcke zeigen damit eher eine punktuelle Nutzung als einen intensiven, durchgehenden Einsatz.

Softwareentwicklung ist über die letzten Jahrzehnte kontinuierlich zugänglicher geworden, zuletzt insbesondere durch KI-Agenten. Programmiersprachen sind allerdings auch in der Vergangenheit bereits immer zugänglicher geworden. So haben sich Sprachen von systemnahen, komplexen Sprachen hin zu höher abstrahierten, leichter zugänglichen Konzepten entwickelt. Mit der Nutzung natürlicher Sprache durch KI-Modelle wird diese Entwicklung aber nochmal verstärkt.

Um diese These besser einordnen zu können, betrachten wir in dieser Auswertung die Qualität und den Umgang mit generiertem Code über verschiedene Nutzergruppen hinweg. Dafür nutzen wir die folgende zentrale Metrik:

• Suggestion-Acceptance Rate: der Anteil von durch KI vorgeschlagenem Code (LOC), der am Ende tatsächlich übernommen und in die Codebasis integriert wird

Die Werte sind sowohl über den Zeitverlauf als auch als durchschnittliche Tageswerte dargestellt.

Die Auswertung zeigt, dass Junior-Entwickler:innen mit 42,1 % einen höheren Anteil der generierten Vorschläge übernehmen als Senior-Entwickler:innen mit 31,5 %. Dieser Unterschied ist über den gesamten betrachteten Zeitraum stabil.

Das deutet darauf hin, dass sich die Bewertung von KI-Vorschlägen je nach Erfahrung unterscheidet. Senior-Entwickler:innen scheinen selektiver zu entscheiden, welche Vorschläge sie übernehmen und welche nicht. Wären die Vorschläge durchgängig passend, korrekt und kontextgerecht, wäre zu erwarten, dass auch erfahrene Entwickler:innen einen höheren Anteil übernehmen.

Der klassische Lern- und Problemlösungszyklus in der Softwareentwicklung basiert auf Iteration: Code schreiben, Fehler machen, Ursachen verstehen, neue Ideen entwickeln und bessere Lösungen ableiten. Dieser Feedback-Loop kann sich verkürzen, wenn KI Vorschläge liefert, die direkt übernommen werden, ohne dass sich Entwickler:innen tiefer mit dem eigentlichen Problem auseinandersetzen.

Das lässt sich auch positiv interpretieren: Wenn KI mehr Umsetzung übernimmt, werden bestimmte Entwicklungsaufgaben auch für Menschen ohne klassischen Softwareentwicklungs-Hintergrund zugänglicher. Die zentrale Frage bleibt aber, ob KI damit wirklich Problemlösung ersetzt oder nur verschiebt, wo sie stattfindet. Denn KI generiert Vorschläge auf Basis gelernter Muster und nicht aus einem eigenen Verständnis von Systemkontext. Ob das bereits als echte Intelligenz gilt, gehört eher in die AGI-Debatte. AGI steht für „Artificial General Intelligence“, also eine KI, die Aufgaben ähnlich flexibel und eigenständig lösen könnte wie ein Mensch.

Um diese These besser einzuordnen, betrachten wir Nutzungsmuster und die Anzahl der Iterationen bis zur Annahme einer vorgeschlagenen Lösung. Sie dienen uns als Indikator dafür, wie stark KI eher als direkter Lösungsgeber oder als Unterstützung im Problemlösungsprozess eingesetzt wird.

Für die Analyse betrachten wir zwei zentrale Metriken:

• Usage Frequency: Wie häufig KI-Agenten als Unterstützung in der Entwicklung genutzt werden.

• Generation/Accept Ratio: Wie viele angestoßene Generierungen beziehungsweise Prompts nötig sind, bis daraus Codevorschläge angenommen werden.

Die Werte betrachten wir sowohl über den Zeitverlauf als auch als durchschnittliche Tageswerte.

Die Auswertung zeigt, dass KI regelmäßig genutzt wird, aber nicht durchgehend den Entwicklungsprozess ersetzt.

• Senior-Entwickler:innen nutzen KI an rund 58 % der Tage, Junior-Entwickler:innen an rund 46 % der Tage. Auch im Zeitverlauf bleibt die Nutzung schwankend und erreicht in keiner Gruppe eine vollständige oder konstante Abdeckung.

• Das spricht dagegen, dass KI als dauerhafter Ersatz für eigenes Arbeiten verstanden wird. Vielmehr scheint sie situativ eingesetzt zu werden, also dann, wenn Entwickler:innen einen konkreten Mehrwert erwarten.

In Ergänzung dazu zeigt die Generation/Accept Ratio, wie viele Generierungen im Schnitt notwendig sind, bis ein Vorschlag angenommen wird. Ein Wert von 3 bedeutet also: Im Durchschnitt werden drei Vorschläge erzeugt, bevor einer übernommen wird. Das ist ein Hinweis, in wie weit dass KI-Ergebnisse dirket verwendet werden können, oder ob ein Auswahl-, Bewertungs- und Verbesserungsprozess notwendig ist.

• Junior- und Senior-Entwickler:innen haben ein fast gleiches Verhältnis: Junior-Entwickler:innen kommen auf einen Wert von 3,0, Senior-Entwickler:innen auf 3,2. Der oft vermutete Unterschied, dass Junior-Entwickler:innen Vorschläge schneller übernehmen und Senior-Entwickler:innen deutlich kritischer iterieren, lässt sich anhand dieser Metrik nicht bestätigen. Beide Gruppen durchlaufen einen ähnlichen Iterationsprozess, bevor Code verwendet werden kann.

• Der Unterschied liegt daher weniger darin, ob KI-Vorschläge geprüft und verworfen werden, sondern eher darin, wie häufig dieser Prozess angestoßen wird. Senior-Entwickler:innen öffnen diesen KI-gestützten Problemlösungszyklus häufiger und nutzen ihn regelmäßiger. In Verbindung mit den vorherigen Auswertungen, etwa zu Effective Lines of Code, deutet das darauf hin, dass Erfahrung weiterhin eine wichtige Rolle spielt. Seniors scheinen KI nicht einfach mehr zu nutzen, sondern sie gezielter zu steuern und in größere Arbeitsschritte einzubinden.

Shift Left, Shift Up: Wie sich die Arbeit als Entwickler:in verändert

In den vorigen Abschnitten haben wir häufig zitierte Thesen diskutiert. Nun treten wir einen Schritt zurück und schauen auf Veränderungen im Alltag der Softwareentwicklung. Aktuelle Studien zeigen, dass KI-Tools in den Arbeitsalltag integriert sind. So ergab ein aktueller Google-DORA-Bericht, dass etwa 90 % der Entwickler:innen inzwischen KI-Technologien nutzen, aber nur rund ein Viertel ihnen stark vertraut ¹ (insbesondere auch weil KI-Code ca. 1.7x mehr Fehler produziert ⁷). Es zeigen sich vier zentrale Verschiebungen, die die Entwicklungsarbeit verändern:

Vom Implementieren zum Orchestrieren

Die aktuelle Forschung bestätigt, dass sich die Rolle von Softwareentwickler:innen vom manuellen Implementieren hin zum Orchestrieren von KI-Agenten verschiebt ¹ ². Anstatt Code zu schreiben, steuern Entwickler:innen heute Ziele, Spezifikationen und Workflows für KI-Agenten und prüfen deren Ergebnisse. Dieses neue Paradigma erfordert andere Fähigkeiten. Insbesondere die Kontextintegration und die präzise Formulierung von Anforderungen und Prompts gewinnen an Bedeutung ¹. Entwickler:innen verwenden mehr Zeit auf Planung und Review (z. B. „Problem Framing“ und Spezifikationssicherheit) und weniger auf das reine Schreiben/Programmieren ¹ ². Für die Entwickler:innen-Rollen bedeutet dies iterativere und parallelere Abläufe zu steuern. Mehrere KI-gestützte Ansätze werden gleichzeitig generiert und später konsolidiert. Empirische Umfragen bestätigen jedoch, dass das Vertrauen in KI-Ausgaben begrenzt ist (nur etwa 43 % der Befragten vertrauen ihrer Genauigkeit) ³. Risiken bestehen insbesondere in erhöhter Komplexität und Koordinationsaufwand beim Einsatz mehrerer Agenten (es gibt keinen spezifischen Peer-Review-Fund) sowie in fehlerhaften oder unsicheren Vorschlägen. Ungeachtet der Automatisierung bleibt die letztliche Verantwortung bei der Entwicklerin bzw. dem Entwickler: Sie bzw. er muss die Qualität und Sicherheit der KI-Ergebnisse validieren ³ ¹.

Shift Left: Qualität verschiebt sich nach vorne

Unter „Shift Left“ versteht man, QA- und Testaufgaben frühzeitig in die Programmierphase zu verlagern, um Probleme idealerweise bereits während der Umsetzung zu entdecken ². KI-gestützte Werkzeuge können diesen Prozess unterstützen, indem sie aus Anforderungstexten automatisch Testszenarien ableiten oder reale Anwendungsszenarien simulieren ⁴. Entwickler:innen formulieren dafür anfangs Testfälle oder Spezifikationen (ähnlich dem Test-Driven Development), die dann vom Agenten umgesetzt und geprüft werden ⁵. So verlagern sich Qualitätsschleifen noch weiter nach vorne im Zyklus.

Dies erfordert eine höhere Genauigkeit bei der Anforderungsdefinition, da die Qualität von KI-generiertem Code stark davon abhängt, wie präzise Anforderungen und Prompts formuliert werden (unspezifische Eingaben führen sehr schnell zu Fehlern). Gleichzeitig müssen Randfälle bereits im Design berücksichtigt werden: Studien zeigen hier, dass generative Modelle bei komplexen Edge Cases oft nicht funktionieren ³.

Insgesamt werden klare Spezifikationen und umfassende Tests somit zum Produktivitätsmultiplikator. „Shift Left” führt zudem dazu, dass die Anforderungsdefinition und Validierung stärker teamübergreifend organisiert werden müssen. Produkt, Design und Technik teilen sich diese Aufgabe. Letztlich bleibt die Verantwortung für Test und Review beim Menschen, auch wenn KI die Erkennung von Fehlern beschleunigt ² ³.

Review wird wichtiger als Writing

96 % der Entwickler:innen vertrauen KI-generiertem Code nicht vollständig ⁶, und empirische Analysen zeigen, dass KI-Tools etwa 1,7-mal mehr Fehler (inkl. schwerer Bugs) produzieren als menschlicher Code ⁷. Folglich wird Review zu einer kritischen Kernkompetenz. An die Stelle des bloßen Programmieren tritt das schnelle Verstehen, Hinterfragen und Validieren von Ergebnissen. Der Fokus liegt dabei weniger auf Stilfragen, sondern auf Logik, Architektur und Edge Cases. Es geht darum sicherzustellen, dass der Code tatsächlich die Anforderungen erfüllt.

Das bedeutet auch: Die Verantwortung bleibt bei den Entwickler:innen. KI kann Vorschläge liefern, aber sie übernimmt keine Haftung für Fehler. Es entsteht Spannungsfeld zwischen Automatisierung und menschlicher Kontrolle ⁶ ⁷.

Sicherheitsaspekte gewinnen weiter an Bedeutung. Beispielsweise finden sich in etwa 12–18 % der KI-generierten Python-Codeblöcke CWE-Schwachstellen ⁸. In der Praxis verschiebt sich deshalb der Schwerpunkt auf gründliche Code-Reviews als Teil des Risikomanagements. Pull-Requests und formale Freigaben werden wichtiger, und Teams etablieren klarere Prüfprozesse für KI-Code. Langfristig entsteht ein Rollenbild, das eher an einen Auditor erinnert: Die Fähigkeit, Code rasch inhaltlich zu bewerten und Schwachstellen zu erkennen, wird zur zentralen Developer-Qualifikation.

Rapid Prototyping wird Standard, aber nicht das Ziel

GenAI übernimmt insbesondere in den Bereichen Design, Implementierung und Testvorbereitung und bringt Zeitersparnisse für die Erstellung früh lauffähiger Prototypen begünstigt ⁹. Insgesamt wird von messbaren Produktivitätszuwächsen bei Softwareaufgaben insbesondere durch kürzere Iterationszyklen und mehr „erste Versionen“ berichtet ¹⁰. Rapid Prototyping wird häufiger als Standard genutzt, da Hypothesen schneller in ausführbare Ergebnisse übersetzt und mit Nutzerfeedback abgeglichen werden können ⁹. Gleichzeitig ist die Übertragbarkeit dieser frühen Ergebnisse auf produktionsnahe Implementierungen begrenzt, da Modelle bei stärker kontextabhängigen, abhängigen Programmierungen/Software-Projekten deutlich schlechter abschneiden als bei der Erstellung kleinteiligen Snippets und Tools ¹².

Die Folge ist eine stärkere Trennung zwischen „erste Version erzeugen“ und „robust machen“: Die erste Phase wird beschleunigt, während die zweite aufwandsintensiv bleibt und Architektur-, Schnittstellen- sowie Wartbarkeitsentscheidungen erfordert ¹². Aus DORA-Analysen geht hervor, dass die Adoption von KI zwar mit höherem Durchsatz in Verbindung stehen kann, aber weiterhin mit geringerer Lieferstabilität korreliert, wenn Kontrollmechanismen und Feedbackschleifen nicht ausreichend sind ¹¹. In diesem Sinne steigt das Risiko, dass schneller erzeugte Änderungen mehr Nacharbeit auslösen, wenn Validierung, Tests und Release-Disziplin nicht proportional mitsteigen ¹³. Große Repository-Studien über mehrere Assistenzsysteme hinweg zeigen zudem, dass KI-beeinflusste Commits häufig Code-Smells sowie nicht triviale Anteile an Bugs und Security-Issues einführen. Ein Teil dieser Probleme verbleibt über längere Zeit im Codebestand ¹³.

Damit wird die „Prototype Trap“ auch organisatorisch relevant: Prototypen, die ohne klare Übergabekriterien in den Produktivcode wandern, erhöhen die Wahrscheinlichkeit kumulierender Wartungs- und Qualitätskosten ¹⁵. In LLM-basierten Systemen entsteht ergänzend eine zusätzliche technische Schuld, weil kurzfristige Prompt- und Parameter-Tweaks als schnelle Fixes genutzt werden und sich verfestigen können (z.B. in Form von Self-Admitted Technical Debt, kurz SATD) ¹⁴. Rapid Prototyping ist somit vor allem ein Lerninstrument, dessen Ziel die schnellere Validierung von Problem und Lösung ist, nicht die schnellere Fertigstellung eines produktionsreifen Systems ⁹ ¹³. Praktisch bedeutet dies, dass Teams explizite „Definition of Prototype“- und „Definition of Done“-Grenzen benötigen, um die Übergänge in die Bereiche Stabilisierung, Security und Observability planbar zu machen.

Vom Narrativ zur Umsetzung: Wie wir weiter vorgehen

Wir sind dabei die Nutzung Copilot und ergänzenden KI-Agenten bewusst zu begleiten. Wir nutzen unseren Metriken, um kontinuierlich zu beobachten wie sich unsere Arbeitsweisen über die Zeit verändern. Uns geht es nicht nur um Effizienz, sondern darum zu verstehen, wie sich die Rolle von Entwickler:innen konkret weiterentwickelt, und um sicherzustellen, dass alle bei uns in der Organisation Teil des Wandels sind. Damit orientieren wir uns auch an drei zentralen Erfolgsfaktoren aus der McKinsey-Studie: praxisnahes Training und individuelle Begleitung, das Tracking von Outcome-Metriken sowie klare KI-Ziele für Produkt- und Entwickler:innen-Rollen ¹.

Wir starten mit einigen konkreten Initiativen:

• Review-Guidelines für KI-generierten Code: Es soll ein gemeinsames Verständnis darüber entwickelt werden, wie Code aus Copilot und Agenten bewertet wird. Welche typischen Fehlerbilder gibt es? Worauf achten wir bei Architektur, Sicherheit und Edge Cases? Ziel ist es, das Review als Kernkompetenz im Team systematisch zu stärken.

• „Prompt Patterns“ und Best-Practices-Library: Sammlung wiederverwendbarer Prompts, Workflows und Patterns aus dem Team. Diese Sammlung ist keine statische Dokumentation, sondern eine lebendige Wissensbasis, die zeigt, wie komplexere Aufgaben strukturiert und effizient mit KI gelöst werden können.

• Exploration und Stabilisierung müssen klar getrennt werden. Durch die Einführung klarer Phasen und Kriterien („Definition of Prototype“ vs. „Definition of Done“) wird das Rapid Prototyping bewusst genutzt, ohne dass technische Schulden aufgebaut werden. Die Teams entscheiden aktiv, wann eine Lösung explorativ bleibt und wann sie produktionsreif gemacht wird.

• Ticket Engineering Guide als neue Kernkompetenz: Weiterentwicklung unserer Ticket-Struktur hin zu präzisen, KI-lesbaren Spezifikationen. Entwickler:innen werden bewusst früher eingebunden, um Anforderungen, Edge Cases und Akzeptanzkriterien mitzugestalten. Ziel ist es, Tickets nicht nur als Übergabepunkte, sondern als zentrale Steuerungsartefakte für Mensch und KI zu etablieren.