Ein möglicher neuer Ansatz: Von der Absicht direkt zur Ausführung
Was wäre, wenn KI nicht mehr Code für Menschen schreiben müsste, sondern direkt eine ausführbare Repräsentation für Maschinen erzeugt? Ein Blick auf den möglichen Übergang von Programmierung als Code-Erstellung zu Spezifikation und Suche nach ausführbaren Lösungen.
Entwickler:innen, Tech-Leads, CTOs und alle, die die Zukunft von Compiler + KI mitdenken
Grundinteresse an LLMs, Compilern und Softwarearchitektur
Was wäre, wenn KI nicht mehr Code für Menschen schreiben müsste, sondern direkt eine ausführbare Repräsentation für Maschinen erzeugt?
Wir haben uns daran gewöhnt, Programmierung als eine Kette von Übersetzungen zu betrachten:
Mensch
↓
natürliche Sprache
↓
Python / Java / C / Rust
↓
Compiler
↓
IR
↓
Assembly
↓
Maschinencode
↓
CPU / GPU
Mit generativer KI verschiebt sich diese Kette bereits:
Mensch
↓
natürliche Sprache
↓
KI
↓
Python / C++ / Rust
↓
Compiler
↓
Maschinencode
↓
Hardware
Die interessante Frage lautet deshalb:
Brauchen wir die Programmiersprache als Zwischenschicht überhaupt noch, wenn die KI die Absicht des Menschen direkt in eine für die Zielhardware geeignete Repräsentation übersetzen kann?
Die Antwort ist nicht einfach „ja“ oder „nein“. Aber als möglicher neuer Ansatz ist die Idee sehr interessant – und sie wird tatsächlich bereits in verschiedenen Forschungsrichtungen und Projekten diskutiert.
1. Programmiersprachen waren ursprünglich eine Abstraktion für Menschen
Eine CPU braucht keine Python-Datei. Sie braucht Maschineninstruktionen.
Wenn wir schreiben:
result = a + b
ist das für den Prozessor nur eine sehr hoch abstrahierte Beschreibung.
Irgendwann wird daraus eine Folge von Operationen wie:
mov rax, rdi
add rax, rsi
ret
und schließlich binäre Instruktionen.
Die Entwicklung der Programmiersprachen lässt sich deshalb auch als eine Geschichte zunehmender Abstraktion verstehen:
Maschinencode
↑
Assembly
↑
C
↑
C++ / Rust / Java
↑
Python / JavaScript
↑
natürliche Sprache
Jede zusätzliche Ebene macht Programmierung für Menschen einfacher – gleichzeitig muss sie irgendwann wieder in eine niedrigere Repräsentation übersetzt werden.
2. Was verändert KI an diesem Modell?
Ein LLM kann bereits heute aus einer Beschreibung ein Programm erzeugen:
„Erstelle einen HTTP-Server,
der 100.000 Anfragen pro Sekunde
verarbeiten kann.“
↓
... sehr viel Code ...
↓
Compiler
↓
Maschinencode
Das ist praktisch.
Aber die KI hat eigentlich zwei verschiedene Aufgaben:
- Sie muss verstehen, was wir wollen.
- Sie muss eine Implementierung in einer menschlichen Programmiersprache formulieren.
Der zweite Schritt existiert vor allem deshalb, weil Menschen den Code lesen, verändern, reviewen und versionieren wollen.
Wenn die KI diese Aufgaben zunehmend selbst übernimmt, stellt sich die Frage:
Warum muss das Modell überhaupt erst eine Sprache für Menschen erzeugen?
3. Der mögliche neue Ansatz
Man könnte die Pipeline stattdessen so gestalten:
MENSCH
│
▼
ABSICHT / SPEZIFIKATION
│
┌───────┴───────┐
│ │
│ Ziel │
│ Constraints │
│ Beispiele │
│ Hardware │
│ Tests │
│ │
└───────┬───────┘
▼
KI-MODELL
│
Verstehen + Planen
│
▼
OPTIMIERTE IR / DSL
│
┌────────┴────────┐
│ │
▼ ▼
Assembly Maschinen-
/ Kernel code
│ │
└────────┬────────┘
▼
CPU / GPU / NPU
│
▼
AUSFÜHRUNG
│
▼
Tests / Messungen
│
└──────► Feedback
Der entscheidende Unterschied:
Die Programmiersprache ist nicht mehr das Produkt.
Sie wird zu einer möglichen internen Repräsentation – oder verschwindet sogar vollständig aus der sichtbaren Pipeline.
4. Warum nicht direkt 0 und 1?
Hier muss man die ursprüngliche Idee etwas präzisieren.
Ein Modell könnte theoretisch direkt Binärcode erzeugen.
Zum Beispiel:
01001000 10001001 11111000 ...
Aber das ist wahrscheinlich nicht die optimale Zwischenrepräsentation für eine KI.
Ein einzelnes Bit trägt extrem wenig semantische Information.
Assembly ist bereits wesentlich strukturierter:
mov rax, rdi
add rax, rsi
ret
Und eine speziell entwickelte IR könnte noch mehr Bedeutung pro Token ausdrücken:
LOAD rdi
LOAD rsi
INT_ADD
RETURN
Noch höher könnte eine hardwareorientierte IR aussehen:
PARALLEL_ADD
INPUT: vector<float>
WIDTH: 16
TARGET: AVX-512
Damit kann das Modell viel direkter über das eigentliche Problem nachdenken.
Der interessante Schritt ist daher wahrscheinlich nicht „LLM → Bits“, sondern „LLM → möglichst kompakte, strukturierte, ausführbare Repräsentation“.
5. Der Compiler könnte vom Übersetzer zum Verifikator werden
Das verändert auch die Rolle des Compilers.
Heute:
Quellcode
↓
Compiler
↓
Maschinencode
In einem möglichen zukünftigen System:
Absicht
↓
KI
↓
ausführbare Repräsentation
↓
Compiler / Verifier
↓
Hardware
Der Compiler wäre dann weniger der eigentliche „Programmierer“ und stärker ein:
- Optimierer
- Verifier
- Sicherheitsfilter
- Hardwareadapter
- Code-Validator
Das ist ein wichtiger Unterschied.
Man muss nicht unbedingt versuchen, den Compiler abzuschaffen.
Man könnte ihn vielmehr an eine andere Stelle in der Architektur verschieben.
6. Noch interessanter: Die KI könnte die Hardware kennen
Eine klassische Programmiersprache ist relativ hardwareunabhängig.
Das ist normalerweise ein großer Vorteil.
Aber wenn eine KI direkt für eine konkrete Maschine optimiert, kann diese Abstraktion auch hinderlich sein.
Beispielsweise könnte das Modell wissen:
Zielhardware:
NVIDIA GPU
Speicher:
24 GB VRAM
Tensor Cores:
vorhanden
Warp-Größe:
32
Operation:
Matrixmultiplikation
Priorität:
maximale Performance
Dann muss die KI nicht erst einen allgemeinen Algorithmus in CUDA schreiben und darauf hoffen, dass der Compiler daraus eine optimale Implementierung macht.
Sie könnte direkt einen optimalen GPU-Kernel bzw. eine entsprechende Low-Level-Repräsentation erzeugen.
Das ist besonders interessant bei:
- GPU-Kernels
- KI-Inferenz
- Matrixoperationen
- Signalverarbeitung
- wissenschaftlichem Computing
- Embedded-Systemen
- FPGA/ASIC-Zielhardware
7. Der eigentliche Paradigmenwechsel: Code wird zum Implementierungsdetail
Das führt zu einer viel größeren Veränderung als „KI kann besser programmieren“.
Heute denken wir:
Ich programmiere eine Lösung.
Mit einem solchen System würde man eher sagen:
Ich spezifiziere, welches Verhalten ich brauche.
Die KI übernimmt dann:
Problem
↓
Modellierung
↓
Algorithmus
↓
Datenstrukturen
↓
Parallelisierung
↓
Hardware-Mapping
↓
Optimierung
↓
ausführbare Repräsentation
Der Mensch definiert vor allem:
- Was soll passieren?
- Was darf nicht passieren?
- Welche Ressourcen stehen zur Verfügung?
- Wie schnell muss es sein?
- Wie viel Speicher darf verwendet werden?
- Welche Sicherheitsbedingungen gelten?
Der konkrete Code wäre nur noch ein Mittel zum Zweck.
8. Das Interessante daran: Diese Richtung wird bereits erforscht
Die Idee ist keineswegs völlig neu.
Allerdings gibt es einen wichtigen Unterschied zwischen der allgemeinen Vision und dem heutigen Stand der Forschung.
Meta: LLM Compiler
Meta hat 2024 den LLM Compiler vorgestellt. Das Modell wurde speziell auf Compiler-IR, Assembly und Optimierung trainiert. Das Training umfasste laut Meta 546 Milliarden Tokens aus LLVM-IR und Assembly.
Das Modell ist nicht einfach ein „LLM, das statt Python direkt Binärcode schreibt“. Es untersucht vielmehr, wie LLMs Compiler-Optimierung und Low-Level-Code verstehen können.
Meta berichtet unter anderem über Modelle, die Optimierung von Codegröße lernen und Assembly zurück in LLVM-IR übersetzen können.
Das ist ein sehr deutlicher Hinweis darauf, dass die Low-Level-Ebene tatsächlich ein relevantes Ziel für KI-Modelle ist.
Nova: Generative Modelle für Assembly
Auch die Forschung zu generativen Modellen speziell für Assembly existiert bereits.
Das Projekt Nova untersucht ein generatives Sprachmodell für Assembly-Code. Die Autoren weisen darauf hin, dass Assembly für normale LLMs schwierig ist, unter anderem wegen der geringen Informationsdichte und der großen Zahl unterschiedlicher Optimierungsmöglichkeiten.
Das ist bemerkenswert, weil es genau die Grenze zeigt:
Nur ein normales LLM zu nehmen und ihm statt Python einfach Assembly zu geben, reicht offenbar nicht.
Die Architektur und das Training müssen an die Eigenschaften von Low-Level-Code angepasst werden.
Nova: Generative Language Models for Assembly Code
LLMs als Compiler-Optimierer
Noch näher an der Idee ist die Forschung, LLMs nicht als klassische Programmierer einzusetzen, sondern als Optimierungsinstanz innerhalb des Compiler-Prozesses.
2026 erschien beispielsweise Arbeiten zu „Compiler-LLM Cooperation“, bei denen klassische Compileroptimierungen mit LLM-generierten Optimierungen kombiniert werden.
Die Idee:
klassischer Compiler
+
KI-basierte Suche
↓
bessere Implementierung
Das ist wahrscheinlich realistischer als die Vorstellung, dass ein LLM sofort einen kompletten Compiler ersetzt.
Agentic Code Optimization via Compiler-LLM Cooperation
9. Und sogar „Natural Language → Machine Code“ wird bereits ausprobiert
Es gibt inzwischen Projekte, die explizit mit genau dieser Richtung experimentieren.
Ein Beispiel ist prompt2bin, das den Ansatz „Natural language in, verified machine code out“ verfolgt.
Interessanterweise macht das System aber noch etwas sehr Vernünftiges:
Natural Language
↓
formale Spezifikation
↓
LLM
↓
C
↓
Tests + formale Verifikation
↓
Compiler
↓
x86-64
Es überspringt die klassischen Programmiersprachen also konzeptionell auf der Benutzerebene, lässt intern aber weiterhin einen normalen Compiler arbeiten.
Ein weiteres aktuelles Projekt, Semcom, beschreibt einen ähnlichen Gedanken als „semantic compiler“: natürliche Sprache soll in verifizierten Maschinencode übersetzt werden.
10. Warum ist die Idee trotzdem noch nicht gelöst?
Weil ein LLM eine fundamentale Schwäche besitzt:
Es kann plausiblen Unsinn erzeugen.
Bei Python kann ein Compiler zumindest feststellen:
Syntaxfehler
Bei Maschineninstruktionen kann der Code syntaktisch vollkommen korrekt sein und trotzdem:
- falsch rechnen
- Speicher überschreiben
- Deadlocks erzeugen
- Sicherheitslücken enthalten
- auf bestimmten CPUs anders funktionieren
- unnötig langsam sein
Deshalb wird Verifikation in dieser Architektur extrem wichtig.
Ein möglicher Workflow wäre:
ABSICHT
↓
KI
↓
Kandidat A ──────┐
Kandidat B ──────┤
Kandidat C ──────┤
↓ │
Ausführung │
↓ │
Tests │
↓ │
Verifikation │
↓ │
Benchmarking │
↓ │
beste Lösung ◄──┘
Die KI erzeugt also nicht unbedingt eine Lösung.
Sie erzeugt viele mögliche Lösungen.
Die reale Hardware, Tests und formale Methoden entscheiden, welche davon funktioniert.
11. Damit entsteht ein neuer Optimierungsloop
Das könnte langfristig wesentlich interessanter sein als „KI schreibt Code“.
Zum Beispiel:
┌───────────────────────────┐
│ Menschliche Spezifikation │
└─────────────┬─────────────┘
↓
┌──────────────┐
│ KI-Modell │
└──────┬───────┘
↓
Kandidatenprogramme
↓
┌───────────────────┐
│ Compiler / Verifier│
└─────────┬─────────┘
↓
Hardware
↓
Performance-Messung
↓
Fehler / Feedback
│
└───────────────► KI
Damit könnte die KI nicht nur Code generieren, sondern Code evolutionär optimieren.
Das ist ein entscheidender Unterschied.
Die Frage wäre nicht mehr:
„Kann das Modell guten Code schreiben?“
Sondern:
„Kann das Modell durch Ausprobieren, Messen und Verifizieren eine bessere ausführbare Lösung finden?“
12. Ein Beispiel: Matrixmultiplikation
Nehmen wir eine einfache Anforderung:
Multipliziere zwei große Matrizen möglichst schnell auf meiner GPU.
Heute:
Mensch
↓
Python
↓
PyTorch
↓
Inductor / Triton / CUDA
↓
Compiler
↓
GPU machine code
Ein möglicher zukünftiger Ansatz:
Mensch
↓
„Multipliziere A × B.
Maximale Geschwindigkeit.
16-bit floating point erlaubt.“
↓
KI
↓
Hardwareanalyse
↓
Tiling
↓
Memory Layout
↓
Thread Allocation
↓
Tensor Cores
↓
optimierter GPU-Kernel
↓
Benchmark
↓
KI optimiert erneut
Hier ist besonders deutlich, warum die klassische Programmiersprache irgendwann nur noch eine Zwischenrepräsentation sein könnte.
Der Mensch interessiert sich nicht dafür, ob die Lösung am Ende in Python, C++, CUDA oder Assembly geschrieben ist.
Er interessiert sich dafür, dass:
A × B
korrekt und möglichst schnell ausgeführt wird.
13. Aber es gibt einen wichtigen Gegenpunkt: Der Compiler ist nicht unbedingt der Overhead
Die ursprüngliche Idee „KI → direkt Bits ist effizienter, weil der Compiler wegfällt“ ist deshalb nur teilweise richtig.
Der Compiler kostet zwar Zeit und erzeugt zusätzliche Repräsentationen.
Aber diese Kosten sind bei vielen Anwendungen winzig gegenüber:
- dem Training des KI-Modells
- der Inferenz des KI-Modells
- dem Testen
- dem Benchmarking
- der Laufzeit des eigentlichen Programms
Wenn ein LLM mehrere Sekunden braucht, um eine Lösung zu erzeugen, ist es nicht automatisch effizienter, wenn anschließend 50 Millisekunden Compilerzeit eingespart werden.
Der stärkere Vorteil wäre ein anderer:
Die KI könnte die Optimierungsaufgabe direkt auf der niedrigsten sinnvollen Ebene bearbeiten.
Das ist konzeptionell wesentlich interessanter als bloß „Compilerzeit sparen“.
14. Vielleicht brauchen wir deshalb eine neue Zwischenebene
Eine interessante Schlussfolgerung ist:
Die Zukunft ist wahrscheinlich weder Python noch 0 und 1.
Dazwischen könnte eine neue Klasse von Repräsentationen entstehen.
Zum Beispiel:
MENSCH
│
▼
natürliche Sprache
│
▼
KI / Agent
│
▼
┌──────────────────────┐
│ AI-native IR │
│ │
│ • semantisch │
│ • hardwarebewusst │
│ • verifizierbar │
│ • kompakt │
│ • optimierbar │
└──────────┬───────────┘
│
┌────────┼─────────┐
▼ ▼ ▼
CPU GPU NPU
│ │ │
▼ ▼ ▼
Machine Machine Machine
Code Code Code
Diese AI-native IR könnte für Menschen kaum noch interessant sein.
Aber für KI-Systeme wäre sie möglicherweise ideal.
15. Das würde auch erklären, warum „Programmieren“ selbst verschwinden könnte
Wir haben historisch immer wieder eine Abstraktionsebene hinzugefügt:
Maschinencode
↓
Assembly
↓
C
↓
Objektorientierung
↓
High-Level Languages
↓
Frameworks
↓
Cloud / APIs
↓
Natural Language
Jede Stufe entfernt mehr technische Details vom Menschen.
KI könnte diesen Prozess weiterführen.
Die nächste Stufe wäre dann vielleicht:
PROGRAMMIEREN
↓
SPEZIFIZIEREN
↓
VERIFIZIEREN
Der Mensch schreibt nicht mehr:
„Mach einen Hash-Table mit diesen Datenstrukturen.“
Sondern:
„Ich brauche eine Zuordnung von IDs zu Objekten, maximal 2 GB Speicher, weniger als 1 µs durchschnittliche Lookup-Zeit und keine Datenverluste.“
Die KI entscheidet selbst, ob sie dafür einen Hash-Table, B-Tree, perfekt-hashende Struktur oder etwas völlig anderes verwendet.
16. Die eigentliche Herausforderung verschiebt sich
Wenn dieser Ansatz funktioniert, wird die wichtigste Fähigkeit nicht mehr sein:
Code schreiben.
Sondern:
präzise Spezifikationen formulieren und Lösungen verifizieren.
Das könnte eine ziemlich große Veränderung sein.
Denn heute ist Code gleichzeitig:
- Spezifikation
- Implementierung
- Dokumentation
- Schnittstelle zwischen Menschen
- Schnittstelle zwischen Mensch und Maschine
Wenn KI die Implementierung übernimmt, können diese Dinge auseinanderfallen.
Dann könnte ein System beispielsweise speichern:
SPEZIFIKATION
+
CONSTRAINTS
+
TESTS
+
FORMAL PROPERTIES
+
PERFORMANCE TARGETS
und daraus bei Bedarf eine konkrete Implementierung erzeugen.
17. Der vielleicht wichtigste Punkt
Die interessante Zukunftsvision ist deshalb meiner Meinung nach nicht:
„LLMs schreiben bald 0 und 1.“
Das wäre technisch zwar möglich, aber konzeptionell zu kurz gedacht.
Die spannendere Vision lautet:
Die Maschine bekommt nicht mehr Code, sondern eine Absicht mit Constraints – und sucht selbst eine ausführbare Lösung.
Damit würde sich die Rolle der Programmiersprache fundamental verändern.
Sie wäre nicht mehr unbedingt die Sprache, in der der Mensch dem Computer sagt, was er tun soll.
Sie wäre möglicherweise nur noch eine von vielen internen Repräsentationen, mit denen die KI arbeitet.
Und dann könnte die Pipeline irgendwann tatsächlich so aussehen:
┌──────────────┐
│ MENSCH │
│ │
│ „Was will │
│ ich?“ │
└──────┬───────┘
│
▼
┌──────────────┐
│ KI │
│ │
│ verstehen │
│ planen │
│ optimieren │
│ verifizieren │
└──────┬───────┘
│
▼
┌──────────────┐
│ AUSFÜHRBARE │
│ REPRÄSENTATION│
└──────┬───────┘
│
▼
┌──────────────┐
│ HARDWARE │
└──────┬───────┘
│
▼
Ergebnis
│
└──────────► Feedback an die KI
Absicht → Ausführung.
Das wäre nicht einfach die nächste Programmiersprache.
Es wäre ein möglicher Übergang von Programmierung als Code-Erstellung zu Programmierung als Spezifikation und Suche nach ausführbaren Lösungen.
Fazit
Der Gedanke ist also nicht neu, aber auch keineswegs „bereits gelöst“.
Es gibt heute mehrere deutlich verwandte Forschungsrichtungen:
- LLMs für LLVM-IR und Assembly-Optimierung
- generative Modelle für Assembly
- LLMs als Compiler-Optimierer
- Compiler-LLM-Kooperation
- formale Verifikation von KI-generiertem Low-Level-Code
- Natural-Language-to-Machine-Code-Projekte
Die einzelnen Bausteine existieren also bereits.
Was noch weitgehend fehlt, ist die vollständige Synthese:
Absicht
↓
KI-Modell
↓
hardwarebewusste Planung
↓
ausführbare IR
↓
direkte Optimierung
↓
Verifikation
↓
Hardware
↓
Messung
↓
Selbstoptimierung
↺
Genau diese Kombination halte ich für den interessanteren möglichen neuen Ansatz.
Nicht „KI ersetzt den Programmierer“, sondern:
Der Code selbst wird möglicherweise zu einer internen Implementierungsform – während die eigentliche Programmierschnittstelle zwischen Mensch und Maschine die Spezifikation von Absicht, Constraints und gewünschtem Verhalten wird.
Weiterführende Quellen
- Meta, Large Language Model Compiler: Foundation Models of Compiler Optimization (2024): https://ai.meta.com/research/publications/meta-large-language-model-compiler-foundation-models-of-compiler-optimization/
- Jiang et al., Nova: Generative Language Models for Assembly Code with Hierarchical Attention and Contrastive Learning (2023): https://arxiv.org/abs/2311.13721
- Agentic Code Optimization via Compiler-LLM Cooperation (2026): https://arxiv.org/abs/2604.04238
- LLM-VeriOpt: Verification-Guided Reinforcement Learning for LLM-Based Compiler Optimization (CGO 2026)
- Code generation with large language models: a survey from neural program synthesis to autonomous software development (2026): https://link.springer.com/article/10.1007/s10489-026-07230-0
- prompt2bin: https://pypi.org/project/prompt2bin/
- Semcom: https://semcom.ai/