KI-Coding kann mittelständischen Unternehmen interne Anwendungen, Automatisierungen und Prototypen deutlich schneller liefern, wenn KI nicht allein über Architektur, Sicherheit und Freigabe entscheidet. Vibe Coding eignet sich vor allem zum Erkunden und Prototyping, nicht als Betriebsmodell für geschäftskritische Software. Entscheidend sind definierte Anforderungen, Versionskontrolle, automatisierte Tests, unabhängige Reviews und ein verantwortlicher Betreiber.
Was ist Vibe Coding und wie unterscheidet es sich von professionellem KI-Coding?
Vibe Coding beschreibt eine Arbeitsweise, bei der ein Mensch einer KI in natürlicher Sprache erklärt, welche Anwendung oder Funktion entstehen soll, die erzeugten Ergebnisse ausprobiert und anschließend über weitere Prompts verändert. Der Begriff wurde 2025 von Andrej Karpathy geprägt und bezog sich ursprünglich ausdrücklich auf eine sehr lockere Vorgehensweise, bei der der Entwickler den erzeugten Code teilweise gar nicht mehr im Detail liest.
Für Experimente ist genau das reizvoll. Aus einer Idee für eine kleine Webanwendung kann innerhalb kurzer Zeit ein klickbarer Prototyp entstehen. Ein Mitarbeiter aus Vertrieb, Logistik, Einkauf oder Produktion kann einen bisher abstrakten Prozess erstmals als funktionierenden Ablauf sehen, statt wochenlang Anforderungen in Präsentationen und Tickets zu beschreiben.
Produktives KI-Coding ist jedoch etwas anderes. Hier darf die natürliche Sprache den Entwicklungsprozess vereinfachen, aber sie ersetzt nicht die Engineering-Disziplin. Der Code landet in einem Repository, Änderungen sind nachvollziehbar, Tests laufen automatisiert, Abhängigkeiten werden geprüft und ein Mensch entscheidet, ob das Ergebnis in die produktive Umgebung gelangt.
Der entscheidende Unterschied ist deshalb nicht, ob eine KI programmiert. Er liegt darin, ob das Unternehmen den entstandenen Code wie Software behandelt oder wie einen zufällig funktionierenden Prototyp.
Warum wird KI-Coding gerade für den Mittelstand wirtschaftlich interessant?
Im Mittelstand fehlen häufig nicht die Ideen für Digitalisierung, sondern verfügbare Entwicklungsressourcen. Zwischen ERP, CRM, Dokumentenmanagement, Fertigungsdaten, Excel-Dateien, Kundenportalen und Fachanwendungen existieren zahlreiche kleine Prozesslücken. Für jede einzelne davon ein klassisches Softwareprojekt zu starten, war bisher oft wirtschaftlich nicht attraktiv.
KI-Coding verändert diese Rechnung.
Eine Untersuchung von JetBrains zeigte für 2025, dass bereits 85 Prozent der befragten Entwickler KI-Werkzeuge regelmäßig für Coding und Softwareentwicklung einsetzen. KI-Unterstützung ist damit keine Randtechnik mehr, sondern Bestandteil alltäglicher Entwicklungsarbeit geworden.
Auch Produktivitätseffekte sind messbar, allerdings nicht in jedem Kontext gleich. Eine von Microsoft Research veröffentlichte Untersuchung mit Feldexperimenten bei mehreren Unternehmen kam im kombinierten Ergebnis auf 26,08 Prozent mehr abgeschlossene Aufgaben bei Entwicklern mit einem KI-Coding-Assistenten. Das ist kein allgemeingültiges Versprechen für jedes Projekt, zeigt aber, warum Unternehmen die Technologie ernsthaft erproben.
Für einen mittelständischen Betrieb ist dabei weniger interessant, ob ein Entwickler einige Minuten schneller eine Funktion schreibt. Relevanter ist, ob Vorhaben wirtschaftlich werden, die vorher unterhalb der klassischen Projektgrenze lagen.
Ein internes Werkzeug für Angebotsfreigaben, eine kleine Oberfläche für die Pflege von Stammdaten oder ein Workflow zur Nachbearbeitung von Servicefällen benötigt vielleicht keine große Individualsoftware. Trotzdem kann ein solches Werkzeug jeden Tag Zeit sparen und Medienbrüche vermeiden.
Genau dort besitzt KI-Coding einen starken Hebel.
Welche internen Anwendungen eignen sich besonders gut?
Die besten Kandidaten sind meist keine neuen Kernsysteme. Es sind Anwendungen zwischen den bestehenden Systemen.
Ein Maschinenbauer könnte beispielsweise eine kleine interne Anwendung benötigen, die Prüfprotokolle strukturiert, fehlende Angaben erkennt und anschließend einen bestehenden Freigabeprozess anstößt. Ein technischer Dienstleister könnte Außendienstmeldungen zusammenführen und daraus automatisch Arbeitslisten erzeugen. Im Großhandel kann eine Anwendung Lieferinformationen aus mehreren Quellen in einer einheitlichen Arbeitsansicht darstellen.
Auch kleine Verwaltungsprozesse sind interessant: Datenübernahme aus CSV-Dateien, kontrollierte Stammdatenänderungen, Dokumentenerfassung, Status-Dashboards, interne Suchwerkzeuge, Genehmigungsprozesse oder die Aufbereitung von Daten für ein vorhandenes ERP- oder CRM-System.
Der wirtschaftliche Vorteil entsteht häufig nicht durch eine spektakuläre Anwendung, sondern dadurch, dass ein Mitarbeiter einen wiederkehrenden Prozess nicht mehr aus mehreren Excel-Dateien, E-Mails und Systemmasken zusammensetzen muss.
Weniger geeignet sind dagegen Systeme, deren Fehler unmittelbar zu hohen Schäden führen können, solange keine professionelle Entwicklungs- und Prüfstruktur vorhanden ist. Dazu gehören beispielsweise sicherheitskritische Steuerungen, komplexe Berechtigungsplattformen oder Anwendungen, bei denen falsche Geschäftsentscheidungen automatisch und ohne menschliche Kontrolle ausgeführt werden.
Wo endet der schnelle Prototyp und wo beginnt produktive Software?
Ein häufiger Fehler besteht darin, dass ein Prototyp schleichend zum Produktivsystem wird.
Am Anfang greift die Anwendung auf Testdaten zu. Danach möchte ein Kollege sie ebenfalls nutzen. Anschließend wird eine echte Datenbank angebunden, ein Login ergänzt und irgendwann hängt ein wichtiger Geschäftsprozess daran. Technisch funktioniert alles noch. Organisatorisch weiß jedoch niemand mehr genau, wer für Updates, Sicherheitslücken, Backups oder fehlerhafte Daten verantwortlich ist.
Gerade KI-Coding macht diesen Übergang leicht, weil neue Funktionen schnell ergänzt werden können. Deshalb sollte der Status einer Anwendung bewusst festgelegt werden.
| Dimension | Vibe Coding und Prototyp | Produktionsreifes KI-Coding |
|---|---|---|
| Zweck | Idee und Ablauf erproben | Dauerhaft nutzbaren Geschäftsprozess unterstützen |
| Daten | Testdaten oder begrenzte Beispieldaten | Freigegebene Daten und definierte Datenklassen |
| Änderungen | Schnelle Iteration über Prompts | Branch, Diff, Review und dokumentierte Freigabe |
| Berechtigungen | Möglichst isolierte Umgebung | Rollenmodell und minimale notwendige Rechte |
| Tests | Manuelle Funktionsprüfung | Automatisierte Funktions-, Integrations- und Sicherheitstests |
| Deployment | Vorschau oder Sandbox | Reproduzierbarer Deployment-Prozess |
| Betrieb | Keine langfristige Zusage | Monitoring, Backup, Verantwortlichkeit und Änderungsprozess |
Die Tabelle zeigt auch, warum die Diskussion über KI-Code häufig am falschen Punkt beginnt. Nicht die Herkunft jeder einzelnen Codezeile entscheidet über die Qualität eines Systems. Entscheidend ist die Produktionsumgebung, durch die Änderungen hindurchmüssen.
Warum reicht ein funktionierender KI-Prototyp noch lange nicht aus?
Moderne Modelle sind beim Programmieren erheblich leistungsfähiger geworden. Der Stanford AI Index 2026 berichtet für SWE-bench Verified, einen Benchmark für Software-Engineering-Aufgaben, einen Anstieg von etwa 60 Prozent auf nahezu 100 Prozent innerhalb eines Jahres. Benchmarks sind keine Garantie für reale Unternehmensprojekte, aber sie erklären, warum Coding-Agenten heute deutlich komplexere Aufgaben bearbeiten können als noch kurze Zeit zuvor.
Das Problem liegt an anderer Stelle.
Eine Anwendung kann ihre sichtbare Aufgabe perfekt erledigen und trotzdem unsichere Berechtigungen besitzen. Sie kann Eingaben korrekt verarbeiten, aber sensible Informationen in Logs schreiben. Sie kann mit dem ERP kommunizieren, aber bei einem Timeout denselben Auftrag mehrfach übertragen. Sie kann sämtliche Tests bestehen, weil die KI neben dem Code auch unzureichende Tests geschrieben hat.
Eine aktuelle Untersuchung zur Sicherheit von LLM-generiertem Code kam zu dem Ergebnis, dass sämtliche untersuchten Modelle verwundbaren Code erzeugten und ein großer Teil der gefundenen Schwachstellen hohe oder kritische Schweregrade aufwies.
„Die Anwendung funktioniert“ ist deshalb nur die erste Qualitätsstufe.
Welche Arbeitsweise verbindet Entwicklungsgeschwindigkeit mit belastbarer Qualität?
Die praktikabelste Arbeitsweise ähnelt weniger einem Chat mit einer KI und stärker einer kleinen automatisierten Softwarefabrik.
Am Anfang steht ein begrenzter Auftrag. Nicht „baue eine Einkaufsplattform“, sondern beispielsweise „ergänze im bestehenden Freigabeworkflow eine Ansicht für offene Bestellungen und verwende ausschließlich die vorhandene Rollenlogik“.
Danach erhält die KI den notwendigen Kontext: Architektur, vorhandene Schnittstellen, Coding-Konventionen, Datenmodell, Sicherheitsanforderungen und Akzeptanzkriterien. Sie implementiert innerhalb eines abgegrenzten Arbeitsbereichs und erzeugt eine nachvollziehbare Änderung.
Anschließend beginnt der wichtigere Teil: Prüfung.
Compiler, Linter, Unit Tests, Integrationstests, Dependency Scans und gegebenenfalls statische Sicherheitsanalysen prüfen maschinell, was sich maschinell prüfen lässt. Ein Entwickler oder technisch verantwortlicher Reviewer bewertet Architektur, Nebenwirkungen und fachlich kritische Änderungen. Erst danach wird gemergt und über den vorgesehenen Deployment-Prozess ausgeliefert.
Dass diese Form der Delegation bereits in erheblichem Umfang genutzt wird, zeigt auch GitHub. Für den eigenen Coding Agent berichtete das Unternehmen, dass innerhalb der ersten Monate bereits mehr als eine Million Pull Requests zusammengeführt wurden. GitHub beschreibt dabei selbst die Verschiebung der Entwicklerrolle in Richtung Aufgabenbeschreibung, Delegation und Verifikation.
Genau diese Verifikation ist für Unternehmen der entscheidende Teil.
Was läuft bei KI-Coding in der Praxis typischerweise falsch?
Der häufigste Fehler ist nicht ein spektakulärer Programmierfehler. Es ist fehlender Kontext.
Die KI bekommt die Aufgabe, eine neue Benutzerverwaltung zu bauen, obwohl bereits ein zentrales Rollenmodell vorhanden ist. Sie legt eine zweite Tabelle für Kundendaten an, weil sie das bestehende Datenmodell nicht kennt. Sie implementiert einen neuen API-Endpunkt, obwohl eine freigegebene interne Schnittstelle existiert.
Der Code kann technisch einwandfrei aussehen und trotzdem die Architektur verschlechtern.
Ein zweites Problem entsteht durch zu große Aufgabenpakete. Je mehr Anforderungen gleichzeitig verändert werden, desto schwieriger wird die Prüfung. Kleine Änderungen mit eindeutigen Akzeptanzkriterien lassen sich wesentlich besser testen und zurückrollen.
Der dritte Klassiker ist der sich selbst bestätigende Agent. Die KI schreibt den Code, erstellt die Tests, interpretiert deren Ergebnis und erklärt anschließend ihre eigene Implementierung für abgeschlossen. Das ist bequem, aber bei kritischen Funktionen keine belastbare Qualitätssicherung.
Auch fehlende Betriebsverantwortung fällt oft erst später auf. Eine interne App läuft monatelang problemlos, bis eine API geändert wird oder eine Bibliothek eine Sicherheitslücke enthält. Dann stellt sich heraus, dass zwar jemand die Anwendung gebaut hat, aber niemand sie dauerhaft betreibt.
Wie lässt sich KI-Code sicher prüfen und freigeben?
Der sicherste Ansatz besteht nicht darin, KI-Code grundsätzlich anders zu behandeln als von Menschen geschriebenen Code. Er sollte mindestens denselben Prüfungen unterliegen, bei besonders autonom arbeitenden Agenten eher zusätzlichen.
Dazu gehören getrennte Entwicklungs- und Produktivumgebungen, Versionskontrolle, geschützte Hauptbranches, automatisierte Tests, Dependency Scanning und ein nachvollziehbarer Freigabeprozess. Zugangsdaten gehören in ein Secret Management und nicht in Prompts, Quellcode oder Konfigurationsdateien.
Besonders wichtig sind die Rechte des Coding-Agenten. Ein Agent benötigt selten gleichzeitig Schreibzugriff auf Quellcode, Produktionsdatenbank und Cloud-Administration. Die technische Bequemlichkeit eines weitreichenden Zugriffs steht in keinem guten Verhältnis zu dem möglichen Schaden eines fehlerhaften Befehls.
Für sensible Komponenten sollte außerdem gelten: Wer den sicherheitskritischen Code erzeugt, sollte nicht allein über dessen Freigabe entscheiden. Vier-Augen-Prinzip, automatisierte Gates und revisionsfähige Änderungen sind keine Bürokratie, sondern die Voraussetzung dafür, dass höhere Entwicklungsgeschwindigkeit nicht zu höherem Betriebsrisiko führt.
Welche Rolle spielen Fachabteilungen, IT und externe Partner?
KI-Coding kann die Zusammenarbeit zwischen Fachbereich und IT deutlich verändern.
Fachabteilungen können Prozesse wesentlich konkreter beschreiben. Statt einer abstrakten Anforderung kann ein Prozessverantwortlicher einen funktionierenden Entwurf erstellen, ihn mit Kollegen ausprobieren und anschließend genau zeigen, welcher Ablauf benötigt wird.
Damit wird der Fachbereich jedoch nicht automatisch zum Betreiber einer Softwareplattform.
Die IT bleibt dort wichtig, wo Integration, Identitäten, Datenmodelle, Netzwerke, Security, Backup und Betrieb betroffen sind. Externe Entwickler oder Dienstleister können wiederum Spezialwissen einbringen und produktionsfähige Lösungen aus validierten Prototypen entwickeln.
Eine sinnvolle Aufgabenteilung lautet daher: Der Fachbereich besitzt Problem und Prozess. Die IT besitzt technische Leitplanken und Plattform. Entwickler oder Coding-Agenten setzen Änderungen um. Ein benannter Verantwortlicher entscheidet über den produktiven Einsatz.
Damit verhindert das Unternehmen eine neue Generation von Shadow IT, diesmal nicht aus Excel-Makros und Access-Datenbanken, sondern aus schnell erzeugten Webanwendungen.
Worauf sollte der Mittelstand bei einer GitHub-Copilot-Alternative achten?
Die Toolfrage wird häufig zu früh gestellt.
Ob ein Unternehmen einen IDE-Assistenten, einen terminalbasierten Coding-Agenten oder eine Plattform für komplette Anwendungen einsetzt, ist weniger wichtig als die Einbindung in den Entwicklungsprozess. Das Werkzeug sollte mit der bestehenden Versionsverwaltung, dem Repository-Modell, den Sicherheitsvorgaben und dem CI/CD-Prozess harmonieren.
Wichtige Auswahlkriterien sind der kontrollierbare Kontextzugriff, die Behandlung vertraulicher Unternehmensdaten, konfigurierbare Berechtigungen, nachvollziehbare Änderungen, Modellwahl, Kostenkontrolle und die Möglichkeit, bestehende Entwicklungsregeln automatisch einzubeziehen.
Auch ein technisch sehr leistungsfähiges Werkzeug verliert seinen Vorteil, wenn Mitarbeiter erzeugten Code manuell zwischen Chatfenstern und Produktivsystemen kopieren müssen.
Interessant ist deshalb weniger die Frage „Welche KI kann programmieren?“, sondern „Welche KI kann innerhalb unserer Entwicklungs- und Sicherheitsregeln produktiv arbeiten?“.
Wann rechnet sich KI-Coding wirklich?
Die Rendite entsteht nicht automatisch durch möglichst viel generierten Code.
Ein Unternehmen sollte stattdessen betrachten, welche Arbeit heute liegen bleibt, weil klassische Softwareentwicklung dafür zu teuer oder zu langsam wäre. Dort entstehen neue Möglichkeiten.
Ein manueller Abstimmungsprozess, der täglich mehrere Mitarbeiter beschäftigt, kann ein besserer Kandidat sein als eine technisch anspruchsvolle Anwendung ohne konkreten Nutzen. Gleiches gilt für kleine Schnittstellen, Datenaufbereitungen und Fachbereichswerkzeuge, die bisher durch Tabellen oder wiederholte Handarbeit ersetzt wurden.
Gleichzeitig müssen Folgekosten berücksichtigt werden. Jede neue interne Anwendung erzeugt Wartung, Updates, Monitoring, Berechtigungsverwaltung und irgendwann Änderungswünsche. KI reduziert die Kosten der ersten Implementierung stärker als die organisatorischen Kosten einer dauerhaft betriebenen Anwendung.
Der wirtschaftlich beste Code kann deshalb auch Code sein, den man nicht erzeugt. Wenn ein bestehendes ERP-Modul dieselbe Aufgabe ausreichend erfüllt, sollte KI-Coding nicht zum Selbstzweck werden.
Wie sollte ein Mittelständler heute mit KI-Coding beginnen?
Ein sinnvoller Einstieg beginnt mit einem echten, begrenzten Prozessproblem.
Geeignet ist beispielsweise ein interner Ablauf, der heute durch mehrere manuelle Arbeitsschritte geprägt ist, keine hochkritische Steuerungsfunktion besitzt und dessen Erfolg leicht überprüfbar ist. Daraus entsteht zunächst ein Prototyp mit Testdaten.
Wenn dieser fachlich überzeugt, beginnt nicht einfach die nächste Prompt-Runde. Stattdessen folgt die Entscheidung, ob die Anwendung produktiv betrieben werden soll. Erst dann werden Architektur, Rechte, Datenhaltung, Tests, Monitoring und Verantwortlichkeiten vollständig festgelegt.
Diese Trennung zwischen Experiment und Betrieb ist wichtiger als die Wahl des einzelnen KI-Modells.
GitHub meldete im Juni 2026 nach stark gestiegener Nutzung seiner KI-Coding-Angebote sogar den besten Monat der Unternehmensgeschichte. Das zeigt, wie schnell sich der Markt bewegt. Für den Mittelstand folgt daraus jedoch nicht, jeden Entwicklungsprozess sofort zu automatisieren. Es bedeutet, jetzt eine Arbeitsweise aufzubauen, mit der leistungsfähigere Coding-Agenten kontrolliert eingesetzt werden können.
Der langfristige Vorteil entsteht dann nicht daraus, dass KI möglichst autonom programmiert. Er entsteht, wenn Unternehmen mehr gute Ideen wirtschaftlich in getestete, sichere und wartbare Software übersetzen können.
Häufige Fragen
Was ist Vibe Coding?
Vibe Coding ist eine Form der KI-gestützten Softwareentwicklung, bei der Anforderungen hauptsächlich in natürlicher Sprache beschrieben und Änderungen über wiederholte Prompts erzeugt werden. In seiner ursprünglichen Bedeutung beinhaltet der Ansatz nur wenig detaillierte Codeprüfung. Für Prototypen ist das attraktiv, für produktive Unternehmenssoftware sollte daraus jedoch ein strukturierter Entwicklungs-, Test- und Freigabeprozess werden.
Welche KI kann programmieren?
Moderne große Sprachmodelle und darauf aufbauende Coding-Agenten können Quellcode erzeugen, bestehende Projekte analysieren, Tests schreiben, Fehler suchen und teilweise komplette Entwicklungsaufgaben bearbeiten. Für Unternehmen ist die reine Modellleistung jedoch nur ein Auswahlkriterium. Mindestens ebenso wichtig sind Repository-Integration, Datenschutz, Berechtigungen, Kostenkontrolle, Testmöglichkeiten und die Einbindung in vorhandene Entwicklungsprozesse.
Ist KI-generierter Code sicher?
KI-generierter Code kann sicher sein, sollte aber niemals allein deshalb als sicher gelten, weil er funktioniert oder automatisierte Tests besteht. Modelle können unsichere Bibliotheken, falsche Berechtigungen oder bekannte Schwachstellen erzeugen. Produktiver KI-Code sollte deshalb denselben Security-Gates unterliegen wie anderer Code, einschließlich Review, Dependency-Prüfung, statischer Analyse und Tests kritischer Funktionen.
Kann eine Fachabteilung ohne Entwickler interne Apps bauen?
Für Prototypen und einfache, risikoarme Werkzeuge ist das zunehmend möglich. Sobald reale Unternehmensdaten, Benutzerkonten, Schnittstellen oder geschäftskritische Abläufe betroffen sind, sollte technische Kompetenz eingebunden werden. Die Fachabteilung kann den Prozess und einen funktionierenden Entwurf liefern, während IT oder Entwicklung Architektur, Security, Datenmodell, Integration und dauerhaften Betrieb absichern.
Welche internen Apps eignen sich für KI-Coding?
Besonders geeignet sind überschaubare Fachbereichswerkzeuge, Datenaufbereitungen, Genehmigungsprozesse, interne Suchoberflächen, Dashboards und kleine Integrationen zwischen bestehenden Systemen. Gute Kandidaten besitzen einen eindeutig beschreibbaren Ablauf und einen messbaren Nutzen. Weniger geeignet sind zunächst Anwendungen mit umfangreichen Berechtigungen, sicherheitskritischen Funktionen oder schwer reversiblen automatischen Entscheidungen.
Wie unterscheidet sich KI-Coding von Low-Code?
Low-Code arbeitet meist innerhalb einer vorgegebenen Plattform mit definierten Komponenten, Datenmodellen und Workflows. KI-Coding kann dagegen frei Quellcode, Schnittstellen und komplette Anwendungen erzeugen. Das schafft mehr Flexibilität, erhöht aber auch die Verantwortung für Architektur, Security und Wartung. In vielen Unternehmen werden beide Ansätze nebeneinander bestehen und unterschiedliche Problemklassen abdecken.
Welche GitHub-Copilot-Alternative eignet sich für den Mittelstand?
Die passende Alternative hängt weniger vom Namen des Werkzeugs als von dessen Einbindung in die vorhandene Entwicklungsumgebung ab. Relevant sind unterstützte Repositories, Datenschutz, Modellwahl, Berechtigungskonzept, Kostenkontrolle, Agentenfunktionen und automatisierte Reviews. Ein leistungsfähiger Agent ist nur dann wirtschaftlich interessant, wenn seine Änderungen kontrolliert geprüft, getestet und freigegeben werden können.
Wie verhindert man neue Shadow IT durch KI-Coding?
Unternehmen sollten Fachabteilungen nicht grundsätzlich vom Experimentieren ausschließen, sondern einen vorgesehenen Weg dafür schaffen. Dazu gehören freigegebene Werkzeuge, isolierte Entwicklungsumgebungen, zentrale Repositories und ein definierter Übergang vom Prototyp zur Produktivanwendung. Sobald echte Daten, Schnittstellen oder Benutzer betroffen sind, müssen technische Verantwortlichkeit, Security-Prüfung und Betrieb verbindlich geklärt sein.
Wer trägt die Verantwortung für KI-generierten Code?
Verantwortung kann nicht an einen Coding-Agenten delegiert werden. Für produktiven Code sollte immer ein benannter technischer oder produktverantwortlicher Mitarbeiter zuständig sein. Er muss nicht jede Zeile selbst geschrieben haben, aber nachvollziehen können, was verändert wurde, welche Prüfungen erfolgt sind und wer eine Änderung freigegeben hat. Das gilt besonders für sicherheits- und geschäftskritische Funktionen.
Wann sollte KI-generierter Code nicht produktiv eingesetzt werden?
Nicht ausreichend geprüfter Code sollte nicht eingesetzt werden, wenn Fehler erhebliche Sicherheits-, Datenschutz-, Finanz- oder Betriebsfolgen haben können. Gleiches gilt, wenn niemand die Architektur versteht oder Wartung und Betrieb ungeklärt sind. In solchen Fällen kann KI weiterhin Entwicklung unterstützen, die endgültige Lösung benötigt jedoch einen professionellen Engineering- und Freigabeprozess.
Quellen zu den Kennzahlen
JetBrains, „The State of Developer Ecosystem 2025“: 85 Prozent regelmäßige Nutzung von KI-Werkzeugen für Coding und Entwicklung.
https://blog.jetbrains.com/research/2025/10/state-of-developer-ecosystem-2025/
Microsoft Research, „The Effects of Generative AI on High-Skilled Work“: 26,08 Prozent mehr abgeschlossene Aufgaben im kombinierten Ergebnis der Feldexperimente.
https://www.microsoft.com/en-us/research/publication/the-effects-of-generative-ai-on-high-skilled-work-evidence-from-three-field-experiments-with-software-developers/
Stanford Institute for Human-Centered AI, „The 2026 AI Index Report“: SWE-bench Verified stieg innerhalb eines Jahres von etwa 60 Prozent auf nahezu 100 Prozent.
https://hai.stanford.edu/ai-index/2026-ai-index-report
GitHub, „The new identity of a developer“: mehr als eine Million zusammengeführte Pull Requests mit dem Copilot Coding Agent innerhalb der ersten Monate.
https://github.blog/news-insights/octoverse/the-new-identity-of-a-developer-what-changes-and-what-doesnt-in-the-ai-era/
Weitere Belege
Business Insider, „The AI coding craze gave GitHub its best month ever“
https://www.businessinsider.com/github-best-month-ever-internal-meeting-2026-6
Morkonda, Selim, Assal, „Security of LLM-generated Code: A Comparative Analysis“
https://arxiv.org/abs/2605.23091
Interessante Links
IBM, „Was ist Vibe Coding?“
https://www.ibm.com/de-de/think/topics/vibe-coding
Cloudflare, „Erste Schritte im Vibe Coding“
https://www.cloudflare.com/de-de/learning/ai/how-to-get-started-with-vibe-coding/
NIST, „New NIST NCCoE Resources on DevSecOps and Agentic AI“
https://www.nist.gov/news-events/news/2026/09/new-nist-nccoe-resources-devsecops-and-october-28-webinar-agentic-ai

