Kurz vor Weihnachten 2025 hat Microsoft noch eine "Duftmarke" in Sachen AI gesetzt und angekündigt, allen in C/C++ geschriebenen Code per KI bis zum Jahr 2030 in Rust umzuschreiben. Die "Aufmerksamkeit des Web" ist Galen Hunt von Microsoft zumindest sicher.
Microsoft und die AI-Mission
Von Microsoft Chef, Satya Nadella, ist die Aussage bekannt, dass 30 % des Codes bei Microsoft bereits mittels künstlicher Intelligenz geschrieben wurde. Und es ist bekannt, dass CEO Nadella massiv Druck auf die Belegschaft ausübt, KI im täglichen Arbeitsalltag zu nutzen. Wer nicht mit zieht, wird bei Microsoft rausgeworfen.
Und Nutzer von Microsoft Produkten bekommen halbgare AI-Lösungen zwangsweise aufgedrückt – koste es, was es wolle. Ich denke, wenn diese AI-Lösungen eine bessere Produktqualität bieten, die Sicherheit und der Datenschutz gewährleistet wäre und das Ganze als Opt-In-Angebot daher käme, hätte Microsoft gewonnen. So beginnen immer mehr Nutzer von Microsoft die "Abstimmung mit den Füßen". So viel zur Einstimmung dessen, was nun bekannt wurde.
Der Post eines Microsoft Mitarbeiters
Es ist ein Post vom 20. Dezember 2025, den der Microsoft Software-Engineer Galen Hunt auf LinkedIn veröffentlicht hat (nachfolgender Tweet zeigt einen Ausriss).
Die Botschaft von Galen Hunt lautet, dass er eine Stelle für einen "IC5 Principal Software Engineer" in seinem Team in Redmond zu besetzen habe. Es besteht Anwesenheitspflicht in Redmond – alles in allem nichts ungewöhnliches. Diese Botschaft hätte kaum jemanden hinter dem Ofen hervorgelockt.
Die Verpackung macht den Unterschied
Aber wie es im Leben so spielt, ist nicht das eigentliche Anliegen, sondern die Verpackung, die die Leute triggert. Galen Hunt schrieb in seinem Post:
"Mein Ziel ist es, bis 2030 jede Zeile C- und C++-Code aus Microsoft zu entfernen. Unsere Strategie besteht darin, KI *und* Algorithmen zu kombinieren, um die größten Codebasen von Microsoft neu zu schreiben. Unser Leitstern ist „1 Ingenieur, 1 Monat, 1 Million Zeilen Code".
Kräftiger kann man natürlich nicht ins Feuer blasen. Bis 2030 soll jede in C und C++ geschriebene Code-Zeile bei Microsoft-Produkten verschwinden und durch Rust-Code ersetzt werden, wobei der Ausdruck "neu geschrieben" verwendet wird. Und der "Polarstern", an dem sich alles ausrichtet, lautet: "1 Ingenieur erzeugt pro Monat 1 Million Zeilen Code" in diesem Projekt.
Eine Infrastruktur zur Codeverarbeitung
Um diese bisher unvorstellbare Aufgabe zu bewältigen, hab man bei Microsoft eine leistungsstarke Infrastruktur zur Codeverarbeitung aufgebaut. Die vorhandene algorithmische Infrastruktur erstellt einen skalierbaren Graphen über den Quellcode in großem Maßstab. Die Microsoft KI-Verarbeitungsinfrastruktur ermöglicht es dann, KI-Agenten unter Verwendung von Algorithmen einzusetzen, um Codeänderungen in großem Maßstab vorzunehmen. Der Kern dieser Infrastruktur werde bereits in großem Maßstab für Probleme wie das Verstehen von Code eingesetzt.
Die Aufgabe dieses neu einzustellenden Principal Software Engineers bestehe darin, dem Team dabei zu helfen, die Microsoft Infrastruktur diesbezüglich weiterzuentwickeln und zu erweitern, um die Übersetzung der größten C- und C++-Systeme von Microsoft in Rust zu ermöglichen.
Etwas zurück gerudert
Das Echo, dass dieser Post verursachte (siehe unten) hat Gale bewogen, etwas zurück zu rudern. Heute Nacht hat er folgende Ergänzung zu seinem LinkedIn-Post hinzugefügt:
Update: It appears my post generated far more attention than I intended… with a lot of speculative reading between the lines. Just to clarify…
Windows is *NOT* being rewritten in Rust with AI.
My team's project is a research project.
We are building tech to make migration from language to language possible. The intent of my post was to find like-minded engineers to join us on the next stage of this multi-year endeavor—not to set a new strategy for Windows 11+ or to imply that Rust is an endpoint.
Es sei alles falsch, was da in seinem Post interpretiert worden sei – die Formulierung ist für mich in den Kernpunkten aber klar. Galen Hunt spricht nun davon, dass es ein "Forschungsprojekt" sei. Dort gehe es darum, Code von einer Sprache in eine andere Sprache zu übersetzen. Windows 11 und darüber hinaus würden nicht in Rust neu implementiert.
Der "Aufreger" in der Community
Aber der "Geist, den Microsofts CEO, Satya Nadella, und seine Mannschaft, beschwören, ist nun aus der Flasche". Die Leute lesen schlicht zwischen den Zeilen und spiegeln dieses an den Aussagen, und Handlungen von Microsoft. Der initiale Tweet von The Lunduke Journal, der das Ganze thematisiert und die Diskussion im Internet los getreten hat, steht bei fast 1 Million Aufrufe – ich habe ihn nachfolgend mal eingebunden.
Der Autor des Tweets greift die Aussage "1 Ingenieur erzeugt pro Monat 1 Million Zeilen Code" auf – ein Ding schierer Unmöglichkeit. Ich schätze mal, dass ein normaler Mensch nicht mal eine Million Zeilen Code sichten, geschweige denn lesen und auch noch verstehen kann. Valentin Ignatev, ein Software-Entwickler drückt es im ersten, oben gezeigten Tweet, so aus:
Man I'm so tired but Microsoft just can't stop losing. This will be a colossal failure that they will most likely have to backtrack. You can't even physically READ one million lines a month, let alone understand them.
Gut, nach der Relativierung von Galen Hunt "Sorry Leute, war alles nur Spaß, es ist ein Forschungsprojekt" ist klar: Bei Microsoft bleibt der schlechte und kaum noch wartbare Code als Basis der Produkte erhalten und wird nicht durch noch schlechteren, AI-generierten AI-Code ersetzt. Den AI-Code verwendet Microsoft nur in neuen Projekten, schätze ich mal.
Das KI-Paradoxon in der Code-Generierung
Abschließend verheirate ich noch eine neue Information, die mir die Tage unter die Augen gekommen bin, mit obigem Thema. Die AI-Protagonisten "versprechen" ja gerne, dass mit Hilfe künstlicher Intelligenz die Produktivität von Software-Entwicklern steigt. Die können viel mehr Code in kürzester Zeit weg schaffen. Die Realität in der Praxis deutet aber in eine andere Richtung.
Ich hatte hier im Blog ja mal erwähnt, dass erste Entwickler von AI-Tools zur Code-Generierung weg gehen (siehe Private-Equity-Gesellschaft Apollo reduziert Unternehmensanteile wegen KI-Unsicherheiten). Und im Beitrag Die KI-Blase wird platzen, aber wann? wird angedeutet, dass man erstens die Produktivitätssteigerungen bei AI (auch bei Microsoft) schlicht nicht messen kann, und zweitens Entwickler feststellen, dass die Produktivität nicht steige, sondern eher sinke. Der Aufwand zum Code-Review ist schlicht höher, als wenn ein erfahrener Entwickler den Code gleich selbst schreibt.
Zum 17. Dezember 2025 hat The Register den Beitrag AI-authored code contains worse bugs than software crafted by humans veröffentlicht, der ein weiteres Schlaglicht auf diese Entwicklung wirft. Die Kurzfassung dieses Berichts von CodeRabbit, eine KI-basierte Plattform zur Codeüberprüfung, lautet: "Die Generierung von Code mithilfe von KI erhöht die Anzahl der zu überprüfenden Probleme und deren Schweregrad."
Die KI-basierte Plattform zur Codeüberprüfung hat 470 Open-Source-Pull-Anfragen für ihren Bericht "State of AI vs Human Code Generation" untersucht. Im Durchschnitt enthalten KI-generierte Pull-Anfragen (PRs) jeweils etwa 10,83 Probleme, verglichen mit 6,45 Problemen in von Menschen generierten PRs. Das ist etwa 1,7-mal mehr, wenn KI beteiligt ist, was längere Codeüberprüfungen und ein erhöhtes Risiko für Fehler bedeutet.
Der Bericht kommt zu dem Ergebnis, dass KI-generierter Code deutlich mehr Fehler in Bezug auf Logik, Wartbarkeit, Sicherheit und Leistung enthält als von Menschen erstellter Code. Sieht mir so aus, als ob wir noch einen langen Weg vor uns haben und am Ende des Tages doch scheitern könnten.
Passend zum heutigen Tag: "Ist das nicht eine 'schöne' Bescherung?" In diesem Sinne: Allen Leserinnen und Lesern eine besinnliche Weihnachtszeit. Die nächsten Tage lasse ich einige Beiträge per Konserve hier im Blog einlaufen. Und im Sinne "schöne Bescherung": Ich habe mit meiner Frau verabredet, dass wir uns nix gegenseitig schenken – dann gibt es auch keine "bösen Überraschungen" …
MVP: 2013 – 2016
Das Ziel ist ambitioniert, aber ich würde es nicht gleich als unmöglich abtun. Man mag zu KI stehen wie man will, aber wenn es "nur" drum geht, bestehenden Quellcode in eine neue Sprache zu übersetzen und dabei vielleicht noch bekannte Fehlerquellen zu beseitigen, würde ich erstmal bis 2030 warten, das zu kritisieren. Ich habe auch schon Programme durch viel "Suchen und Ersetzen mit Regular Expressions" in ganz normalen Texteditoren von Pascal nach C übersetzt. Das geht durchaus. Und das war teils von den Datenstrukturen schon eine kniffligere Sache, es ging da um verkettete Listen und Baumstrukuren, also rumgehampel mit Adresszeigern, etwas was in Pascal wirklich schwer umzusetzen war. Von C nach Rust wird wahrscheinlich komplexer, aber das sollte mit Hilfe von KI machbar sein, die Syntax und Logik ist ja bekannt, und genau darin liegt eine Stärke von KI. Der Galen Hunt wird das sicher schon in kleinerem Rahmen ausprobiert haben, bevor er das Ziel definiert hat.
So eine manuelle Umsetzung kann lästig sein. Dabei etwas automatisierte Hilfe zu haben hätte ich mir vor 10 Jahren auch gewünscht als ich ein Projekt von VB nach C# portieren musste
Nun ja, lies mal den Abschnitt "Wenn der Vater mit dem Sohne" in meinem Blog-Beitrag Jubiläum: 28 Jahre Gesamtkunstwerk »Günter Born – ohne Sohn« – es gab da ein Projektchen "VB nach C#" portieren, für ein Buchprojekt. Hab ich mit Sohnemann 2006 durchgeführt, so ganz ohne KI, aber mit einem "Übersetzungstool".
https://borncity.com/blog/2025/12/24/microsoft-will-bis-2030-allen-c-c-code-per-ai-in-rust-umsetzen/?replytocom=241855#respond
als Waldfrühling
Stichwort UML:
Kennt jemand noch die 'Anfänge' und wie das die ersten Jahre gehypt wurde?
Alles super toll, man malt Klassen, Sequenzen, Timing, Komponenten, etc. -Diagramme, alles ganz toll und so einfach (Bedienung, Verbindungen herstellen, ..) und die tollen Tools 'verstehen' was gemeint ist, können bestehende Sourcen (egal ob z.B. C/C++, ASM, SQL, XML, was auch immer) einlesen (tausende, hunderttausende, Millionen Zeilen von Code), daraus dann automatisch die Abhängigkeiten erkennen, modelieren.
GUI für Klick-and-Draw-and-Run, automatische Source-Generierung, 'egal' welche Sprache oder sogar Mixed-Sources, inkl. Konnektoren, APIs, usw.
Man sollte wirklich integriert alles machen können, sogar händisch in z.B. Klassen eigene Methoden oder Spezialbehandlungen 'in Code' einbringen können.
Hörte sich damals 'super' an, das ist nach den ersten 5 Jahren bis auf kleine Sachen quasi nicht zu gebrauchen gewesen.
Heute hört sich das immer noch 'super' an, hat sich mal jemand intensiver mit den ganzen Spezifikationen beschäftigt?
Ein riesen Monster, wie so vieles gut gemeint, aber Ziel meiner Meinung nach nicht erreicht und wird meiner Meinung nach auch nie erreicht werden können.
Oder wenn man wirklich keine manuellen Ergänzungen im Code braucht, oder diese 'geschickt' seperate Bereiche abkapseln kann. Bloss dann leider öfter das 'Gesamtbild' im Sinne von Hierarchien, APis drunter.
Erfahrung damit in den 1990er bis Anfang 2000, u.a. im Bereich
C/C++ und ASM bei embedded Betriebssyteme, massiv-parallelen Betriebssystemen und verteilte Dateisystemen dafür, in den letzten > 10 Jahren integrierte Datenbanken, Anbindungen an REST APIs.
Fazit damals und heute noch:
Teile mögen und tun es auch heute noch für Visualiesierungen unterstützen, z.B. Klasendiagramme, daneben eigentlich unabhängig Sequenz- und/oder Timing bezeichnen.
Sachen, die in Richtung automatische Codeerzeugung (Multiplattform, Multicode) gehen, nicht wirklich hilfreich und nutzbar.
Da sind durch Buildtools (make, nodejs, …) deutlich besser Plattform-Variationen abzubilden.
Editoren, IDEs mit Code-Completion sind da seit einigen Jahren besser nutzbar, wenn es um eigentliche Programmieren geht.
YMMV
Naja graphische Programmierung etc. funktioniert aber durchaus… und ist in der Industrie mittlerweilen auch verbreitet… Kleinsteuerungen wie die Siemens Logo!; Eaton Easy oder NI LABView… sind halt spezifische Nischen und keine AllinWonder Projekte.
Danke für das darauf Hinweisen, irgendwie im Hinterkopf tief vergraben…
Ohne das ich damit was gemacht habe:
Annahme bzw. Frage: sind die 'Building-Blocks' der einzelnen 'Steuerungskomponenten' dann mit 'fester Logik' definiert, und es sind halt nur vorgesehenen Komponenten untereinander koppelbar (ggf. noch Parameter wie: Wasserdurchfluss 5, 37, 87 Liter)
oder kann bei solchem visuellem Programmieren auch 'freie ABläufe' programmiert werden?
Vielleicht kann mir das hier jemand mal erklären: Was ist so besonders an Rust? Der Linux Kernel wird ja neuerdings auch zum Teil darin geschrieben. Ich verstehe, dass die Sprache Speichersicherheit mitbringt im Vergleich zu C/C++. Aber das macht die Sache doch am Ende auch noch nicht rund, der Programmierer muss doch noch immer ein fehlerfreien Algorithmus programmieren, das passiert in Rust auch nicht von alleine. Also warum gehen viele den massiven Aufwand und migrieren Code nach Rust? C++ hat doch auch mit Smart Pointer eine gewisse Form von Speichersicherheit (soweit ich das als Nicht-Programmierer richtig verstehe). Wieso erweitert man die Sprache C oder C++ nicht um das Feature Set, dass gebraucht wird?
Wenn Du deinen Beitrag exakt so nach "ChatGPT" kopierst, erhältst du eine für Laien verständliche Antwort.
"Veni, vidi, hallucinavi."
Du bekommst 'ne Antwort, die sich das LLM von zig Quellen "zusammengeklaubt" hat und ohne Sinn und Verstand miteinander verkettet hat, ohne den Sinn dahinter auch nur ansatzweise verstanden zu haben.
ChatGPT ist ein besseres Wikipedia-Frontend…
Um es mal "pointiert" zu beantworten ;-)
Bei Vergleichen wird gerne die neueste funktionierende Version von Rust mit einer sehr alten Version der gegenübergestellten Programmiersprache verglichen. Bei C/C++ also mit der Version aus 1989, wenn's hoch kommt mit der ersten ISO-Version ISO/IEC 14882:1998. (Aber das ist auch nichts Rust-Spezielles… So wird die neueste Java-Version gerne mit COBOL 74 (1974) verglichen.)
Und in letzter Zeit wird die Anzahl der Rustinianer (eine religionsähnliche Glaubensgemeinschft) immer größer. "You shall have no other programming language besides me!"
"… goal … eliminate every line … by Microsoft"
naja, was soll man da sonst verstehen, was als Ziel gemeint ist – das mit dem Forschungsprojekt ist nur eine Ausrede
Rust wird bereits öfter dort eingesetzt: https://github.com/microsoft?q=&type=all&language=rust&sort=
Sogar hier: https://github.com/microsoft/edit
und https://www.heise.de/news/Microsoft-stellt-Rust-Repository-fuer-die-Windows-Treiberentwicklung-vor-10633912.html, https://www.techtarget.com/searchenterprisedesktop/answer/Does-Windows-kernel-use-Rust-and-what-does-it-mean-for-IT, https://techcommunity.microsoft.com/blog/windowsdriverdev/towards-rust-in-windows-drivers/4449718
Natürlich wird das noch ein Forschungsprojekt sein, aber das Ziel ist unverändert und MS ist längst auf dem Weg dahin, insbesondere seitdem die US-Regierung von C / C++ abrät und speichersichere Varianten empfiehlt – wäre sonst doof wenn MS die US-Regierung als Kunde verliert
Warum auch nicht.
Man kann mit KI erstmal sehr umfangreiche Tests erzeugen, da müsste es eh schon viel geben bei Microsoft.
Und das eigentliche Ziel von so einer KI wird ja sein, dann auch direkt X86 Maschinencode zu lernen.
Dann kann man eine .dll direkt nach rust/.net/.. was auch immer umwandeln. Funktion für Funktion.
Mir werden auf X immer die Posts von Peter Girnus in den Feed gespült. Peter hat eine unnachahmliche Art, Sachverhalte aufzuspießen und auf den Punkt zu bringen. Eine nette Fundstelle vom 19.12.2025:
Als ob das bei Menschen anders wäre.
Nur ein Mensch kann keine 100k Zeilen unter einmal erfassen, der hat schon bei 10 Zeilen ein Problem.
Und ja, hier passiert sehr viel, gerade Gemini3 von Google ist im Vergleich wiedermal ein echter Meilenstein. Ich habe es gerade für ein kleines Projekt verwendet.. irre.
Der Kontrollverlust, schlägt hier natürlich total durch.
Da gibt es einen Wahrnehmungs-Sprung, die "Großen" kennen den Verlust eh schon lange die haben ja teils Teams nach Indien und Co. ausgelagert, quasi egal wie das innen drinnen aussieht, Hauptsache es entspricht der Spec.
Bei "kleinen" Buden, ist das aktuell ein Problem.. wenn "der" Programierer geht.. ist oft die Firma/Produkt danach nicht mehr brauchbar. Kann man hier einer KI vertrauen?
Wenn ich mir ansehe .. wie viele Menschen hier schon Code-Basen ruiniert haben.. ändert sich eigentlich nicht so viel.
Was sich aber auf jeden Fall ändert ist die Geschwindigkeit. Wer glaubte, die Technik schreitet zu schnell voran, wird nun erleben, dass die IT Industrie die letzten Jahre nur im 1. Gang unterwegs war. Mit allen Folgen für die "Verkehrssicherheit".
LLMs liefern brauchbare Ergebnisse bei grünen Wiesen in einem kleinen Rahmen, das stimmt. Wenn man die Dinger auf eine bestehende Codebase, am besten noch mit Legacy-Code in einer Legacy-Sprache loslässt, sieht das aber wieder anders aus.
> This week we admitted Windows 11 core features are broken
"This week we admitted Windows core features are broken" wäre passender.
Hätte die wirklich eine KI die programmieren könnte würden die den Code entweder auf Fehler abklopfen lassen oder die KI könnte es direkt in Assembly neu schreiben ohne das man die Sprache als von Menschen benötigten Zwischenschritt noch nutzen müßte.
Das Feature von Rust ist die Art und Weise wie mit Speicher Strukturen und Nebenläufigkeit umgegangen wird.
Assembler ist dann schon sehr Hardware bezogen, und nicht jede Hardware kann alles. Da werden also oft Konzepte "umschifft" wie bei einer Hardware Beschleunigung.
Und Microsoft will sicher die Portierbarkeit von seiner Software zwischen x86 und ARM aufgeben.
?
Ich verstehe hier die Aussage nicht
Denk noch mal ganz scharf drüber nach… Ein Betriebssystem, das von der ersten bis zur letzten Codezeile optimal in x86 Assembler geschrieben ist, wie läuft die nochmal auf einer ARM CPU?
Was hat das mit dem Artikel zu tun?
Abgesehen davon ist Windows in C/C++ geschrieben nicht in Assembler ( bis wahrscheinlich auf sehr wenige Teile )
Ich bezog mich nicht auf den Artikel, sondern deinen Kommentar.
Ich halte ja nicht viel von KI, aber genau das sind doch die Stärken von KI: ein fest definierte Satz Regeln zu erfassen und umzusetzen (und mehr ist eine Programmiersprache nicht)… da man die auch sehr bewusst nur darauf trainieren kann, sollte auch keine Halluzinationen dabei rauskommen…
warten wir es ab.
ach so by the day: frohe Weinachten ;-P
Fest definierter Satz Regeln ist gut, in manchen Sprachen wie z.B. C++ ist es noch nicht einmal möglich, einen garantiert funktionieren Parser zu bauen. Und ein Haufen Bugs in allen Compilern kommt dann noch dazu.
Bei C kann es vielleicht noch funktionieren, wenn man nicht zu wilde Syntaxkonstrukte auffindet, aber bei C++ mit Templates und Vererbung sehe ich schwarz.
Und wenn man schon angeblich eine KI hat, die C-Code versteht, dann kann man damit doch auch den existierenden Code nach Bugs durchsuchen, lesbar machen, und kommentieren. Wozu dann noch der Aufwand mit Rust? ;-)
>Abschließend verheirate ich noch eine neue Information
Darf man fragen, wer der Bräutigam ist?
Die Herrschaft der Maschinen hat begonnen:
KI erzeugt den Code, um mehr KI in Windows zu bringen!
mmmmh…Rust!
habe über den Quellcode von Rust viel über Rust gelernt. macht spaß wie C++
"Windows is *NOT* being rewritten in Rust with AI."
Überspezifisches Dementi? Nach der Formulierung bliebe immerhin noch Office und Exchange zu verhunzen…
Tatsächlich verwende ich auch schon KI zum Programmieren im alten VB 6 (ich bin selbst alt, da passt das dann ;-)). Neulich hatte ich folgende Problemstellung: Der Jahreskalender sollte auf dem Monitor im Mehrmonitorbetrieb geöffnet werden, wo sich die Maus befindet. Das kann in VB 6 nur mit einem Griff in die API-Kiste bewerkstelligt werden, da diese Funktion nicht in der Programmiersprache enthalten ist. Auch die Umsetzung von Math. Formeln in VB 6 kann ganz schön nerven. Das überlässt man heutzutage lieber der KI.
Wenn künstliche die natürliche Intelligenz ersetzt, wird es gefährlich. IMHO ist das bei Microsoft schon lange passiert. Ich wundere mich, dass die Microsoft Produkte, wenn auch oft krottenschlecht, überhaupt funktionieren, wo doch gefühlt nur Schwachmaten an den Schaltstellen sitzen. Da kann man nur schreiend davonlaufen.
Dann beginnt also die Debugging- und Fehlerorgie wieder von vorn? Oder haben die auch eine KI, welche bei KI-generierten Code die Fehler korrigiert?