Softwareentwicklung hatte lange einen ziemlich klaren Flaschenhals: Menschen mussten Code schreiben. Sie mussten Syntax beherrschen, Bibliotheken kennen, Schnittstellen verstehen, Tests bauen, Fehler suchen. Das war langsam, teuer und schwer skalierbar. Genau an dieser Stelle greifen Werkzeuge wie GitHub Copilot, ChatGPT-basierte Assistenten und andere KI-Coding-Systeme an.
Die Zahlen zeigen, wie weit diese Verschiebung bereits gegangen ist. In Repositorys, in denen GitHub Copilot aktiviert ist, werden rund 46 Prozent des Codes von KI generiert; die Prognose liegt bei mehr als 50 Prozent bis Mitte 2025. Bei Google sagte Sundar Pichai, dass im April 2026 bereits 75 Prozent des neuen Codes KI-generiert waren, nach 25 Prozent im Oktober 2024 und 50 Prozent Ende 2025. Eine in Science veröffentlichte Studie beziffert den Anteil KI-gestützten Codes in den USA auf 29 Prozent Anfang 2025, nach 5 Prozent im Jahr 2022.
Das ist keine Randerscheinung mehr. Es ist eine neue Produktionsweise. Aber sie löst nicht einfach das alte Problem der Softwareentwicklung. Sie verschiebt es.
Der knappe Faktor ist nicht mehr die Tastatur
Wenn Code schneller entsteht, wird das Schreiben selbst weniger wichtig als seine Bewertung. Unternehmen, die KI-Assistenten einsetzen, berichten von deutlichen Produktivitätsgewinnen. Entwickler nennen durchschnittlich 55 Prozent mehr Produktivität; ein Team mit GitHub Copilot war etwa 50 Prozent schneller. Mehr als 80 Prozent der Softwareentwickler nutzen KI bei der Arbeit, fast die Hälfte täglich. GitHub Copilot kam bis Juli 2025 auf mehr als 20 Millionen Nutzer und im Januar 2026 auf 4,7 Millionen zahlende Abonnenten. 90 Prozent der Fortune-100-Unternehmen setzen das Werkzeug ein.
Das ist der Teil, den Vorstände leicht verstehen. Mehr Code, kürzere Zyklen, weniger Warten auf Boilerplate, schnellere Prototypen. In einer Organisation, in der Backlogs nie kleiner werden, klingt das nach Entlastung.
Nur entsteht damit ein neuer Engpass. Wenn ein Entwickler früher hundert Zeilen schrieb und verstand, was er gebaut hatte, kann er heute in derselben Zeit mehrere Varianten erzeugen lassen, prüfen, verwerfen, übernehmen und umbauen. Die Menge des zu bewertenden Materials steigt. Nicht alles davon ist schlecht. Aber vieles ist nicht ausreichend verstanden, nicht sauber integriert oder nur scheinbar plausibel.
Die strategische Frage lautet deshalb nicht mehr, wie viel Code eine Organisation erzeugen kann. Sie lautet: Wie viel davon kann sie verlässlich prüfen?
Plattformen rücken in den Entwicklungsprozess
Für Microsoft ist GitHub Copilot nicht nur ein Entwicklerwerkzeug. Es ist ein Einstiegspunkt in den Softwareproduktionsprozess von Unternehmen. Wer den Editor, das Repository, den Pull Request und den Assistenzlayer kontrolliert, sitzt nah an der Stelle, an der technische Entscheidungen entstehen. Das erklärt, warum Copilot für Microsoft strategisch weit mehr ist als ein Zusatzprodukt.
Ähnlich positionieren sich Google und AWS mit eigenen Angeboten für KI-gestützte Entwicklung. Der Markt besteht nicht nur aus Textmodellen, die Code vorschlagen. Er besteht aus Integrationen: IDE, Cloud, Repositories, CI/CD, Security-Scanning, Dokumentation, Ticketsysteme, Testautomatisierung. Wer dort mehrere Ebenen verbindet, kann Softwareteams tiefer binden als über klassische Cloud-Preise allein.
Damit verschiebt sich auch die Machtbalance zwischen internen Entwicklerorganisationen und externen Plattformen. Früher war ein Code-Editor austauschbar. Heute wird der Assistent zum Gedächtnis, Vorschlagsapparat und Beschleuniger des Teams. Er kennt Konventionen, erzeugt Tests, schreibt Dokumentation, schlägt Architekturfragmente vor. Je enger er in die Lieferkette eingebaut ist, desto schwieriger wird ein Wechsel.
Der Wettbewerb läuft deshalb nicht nur über Modellqualität. Er läuft über Vertrauen. Und Vertrauen entsteht nicht durch eine höhere Zahl erzeugter Zeilen, sondern durch kontrollierbare Ergebnisse.
Fehler skalieren jetzt mit
Die unangenehme Seite der Produktivität ist ihre Symmetrie: Was schneller richtig gemacht werden kann, kann auch schneller falsch gemacht werden. Experten schätzen, dass 62 Prozent des KI-generierten Codes fehlerhaft oder anfällig sein könnten. Diese Zahl ist kein Beweis dafür, dass KI-Code grundsätzlich unbrauchbar wäre. Sie zeigt aber, wie riskant es ist, Codegenerierung wie eine reine Effizienzmaßnahme zu behandeln.
Der Schaden entsteht selten spektakulär. Meist beginnt er klein: eine ungenaue Fehlerbehandlung, eine unsichere Abhängigkeit, ein zu großzügiger Zugriff, ein Test, der zwar grün ist, aber das falsche Verhalten bestätigt. KI-Systeme sind besonders gut darin, syntaktisch überzeugende Lösungen zu liefern. Gerade deshalb können ihre Schwächen schwerer auffallen. Der Code sieht aus, als gehöre er dorthin.
Für Sicherheits- und Qualitätsteams bedeutet das mehr Arbeit an einer anderen Stelle. Sie müssen nicht nur fertigen Code prüfen, sondern auch den Prozess, der ihn erzeugt. Welche Vorschläge dürfen übernommen werden? Welche Bereiche sind ausgeschlossen? Welche Tests sind Pflicht? Welche sicherheitskritischen Komponenten brauchen menschliche Prüfung? Wie wird dokumentiert, ob ein Modul KI-unterstützt entstanden ist?
Dass schlechte Softwarequalität Geld kostet, ist nicht neu. Der Tricentis Quality Transformation Report 2026 zeigt, dass in Deutschland fast jedes dritte Unternehmen jährlich mehr als eine Million US-Dollar durch mangelhafte Softwarequalität verliert. KI-Code kann diese Kosten senken, wenn er in robuste Prozesse eingebettet wird. Er kann sie aber auch erhöhen, wenn Tempo die einzige Kennzahl bleibt.
Der Entwickler wird nicht ersetzt, sondern umplatziert
Die Rolle des Entwicklers verändert sich dabei weniger in Richtung Passivität, als viele Debatten suggerieren. Wer KI gut nutzt, muss mehr Kontext liefern, Entscheidungen treffen, Architekturgrenzen kennen und Ergebnisse hinterfragen. Das reine Schreiben einzelner Funktionen verliert an Gewicht. Dafür werden Spezifikation, Review, Testdesign und Systemverständnis wichtiger.
Das trifft Junior-Entwickler besonders hart. Gerade der mühsame Teil des Lernens bestand bisher darin, Fehler selbst zu machen, APIs falsch zu nutzen, Tests zu brechen, Annahmen zu korrigieren. Wenn Assistenten diesen Weg abkürzen, steigt kurzfristig die Produktivität. Langfristig kann aber Erfahrungswissen fehlen. Ein Entwickler, der Code nur noch annimmt, ohne ihn wirklich lesen zu können, wird für komplexe Systeme zum Risiko.
Unternehmen müssen deshalb Ausbildung und Prozesse anpassen. KI-gestützte Entwicklung braucht nicht weniger Disziplin, sondern andere Disziplin. Code Reviews müssen stärker auf Semantik achten. Tests müssen gegen plausible, aber falsche Implementierungen schützen. Sicherheitsprüfungen müssen früher greifen. Architekturentscheidungen dürfen nicht aus einer Kette bequem akzeptierter Vorschläge entstehen.
Hier trennt sich der Nutzen von der bloßen Nutzung. Ein Unternehmen, das KI-Assistenten ausrollt und ansonsten alles gleich lässt, bekommt mehr Output. Ob daraus bessere Software wird, ist offen.
Der neue Kontrollpunkt heißt Verifikation
Die Gewinner dieser Verschiebung sind zunächst die Anbieter von Coding-Plattformen. Microsoft mit GitHub Copilot hat dabei eine besonders starke Position, weil GitHub für viele Teams ohnehin der operative Mittelpunkt der Entwicklung ist. Aber auch Anbieter, die Testautomatisierung, Security-Analyse, Codequalität und Governance in den Entwicklungsfluss integrieren, rücken näher an den Wertstrom.
Die Verlierer sind nicht automatisch Entwickler. Verlierer sind Organisationen, die Codevolumen mit Fortschritt verwechseln. Wenn 64 Prozent der Firmen laut einer Jellyfish-Studie den Großteil ihres Codes mit KI-Unterstützung generieren und 63 Prozent KI-Tools für den Großteil ihrer Programmierung nutzen, dann wird KI-Code bald kein Unterscheidungsmerkmal mehr sein. Er wird Normalbetrieb.
Der Unterschied liegt dann in der Fähigkeit, diesen Normalbetrieb zu kontrollieren. Wer gute Spezifikationen, belastbare Tests, klare Sicherheitsregeln und erfahrene Reviewer hat, kann KI als Produktionshebel nutzen. Wer diese Schicht nicht besitzt, beschleunigt vor allem seine eigenen Schwächen.
Damit wird der Anteil KI-generierten Codes zur falschen Hauptkennzahl. 30, 50 oder 75 Prozent sagen wenig darüber aus, ob ein Unternehmen bessere Software baut. Entscheidend ist, ob es die Prüfung im gleichen Maß industrialisiert wie die Generierung.
Softwareentwicklung tritt damit in eine nüchternere Phase ein. Code wird billiger. Vertrauen wird teurer.
