Vor sechs Monaten sollte „Vibe Coding“ alles verändern. Sie sagen der KI, was Sie wollen, lehnen sich zurück und sehen zu, wie funktionierende Software entsteht. Andrej Karpathy, ehemals bei Tesla und OpenAI, pries es als die Zukunft an: Vergessen Sie die Syntax, beschreiben Sie einfach Ihre Absicht. Die Demos waren berauschend. Startups prahlten mit ganzen Codebasen, die GPT-artige Copilots geschrieben hatten. Prototypen standen in wenigen Stunden. Der Traum: Software ohne Softwareentwickler.
Die Realität ließ nicht lange auf sich warten. Der Code funktionierte, eine Woche lang. Dann brach er zusammen. Ein Fintech-Startup stellte fest, dass sein KI-generiertes Authentifizierungsmodul die Passwörter erst prüfte, nachdem es den Zugriff gewährt hatte: eine verdrehte if-Abfrage, die das Modell aus der vagen Anforderung „verify user credentials“ bereitwillig produziert hatte. Das Problem ist nicht die KI, sondern die Art, wie wir mit ihr reden.
Das Englisch reparieren, nicht das Modell
Eine wachsende Gruppe von Forschern sieht die Lösung nicht in mehr GPU-Feuerkraft, sondern in mehr Disziplin bei der Art, wie Menschen Anforderungen beschreiben. Hier kommt die kontrollierte natürliche Sprache (CNL) ins Spiel: eine eingeschränkte Form des Englischen mit strenger Grammatik und festem Vokabular, die Mehrdeutigkeit beseitigen soll.
Stellen Sie es sich als Englisch mit Stützrädern vor: eingeschränktes Vokabular, vorhersehbare Syntax, null Mehrdeutigkeit. Statt das hier zu schreiben:
❌ „Handle overdrafts properly with notifications.“
schreiben Sie das:
✅
Rule: If a customer’s balance falls below 0,
then send an overdraft notification email
within 60 minutes.Beides ist Englisch. Aber nur die kontrollierte Fassung ist so präzise, dass sie sich parsen und validieren lässt und, was entscheidend ist, von einem LLM konsistent verstanden wird. Das kontraintuitive Versprechen: Damit KI-Code brauchbar wird, müssen Entwickler womöglich etwas sprachliche Freiheit aufgeben. Nicht bessere KI, sondern besseres Englisch.
Kontrollierte Prompts in der Praxis
Falls Ihnen das bekannt vorkommt: Das ist es auch. Behavior-Driven Development (BDD) arbeitet seit über einem Jahrzehnt mit strukturiertem „Given/When/Then“-Englisch. Test-Frameworks wie Gherkin zwingen Teams, Anforderungen in einer eingeschränkten Syntax zu schreiben, damit sie ausführbar sind.
Controlled Prompting trägt diese Idee weiter nach vorne in den Prozess. Statt KI-Prompts als einmalige Improvisationen stehen zu lassen, definieren Entwickler Vorlagen. Ein Prototyp, CNL-P (Controlled Natural Language for Prompting), sieht aus wie strukturiertes Frontmatter:
Feature: Calculate loan payments
Context: User provides amount, term, interest rate
Requirements:
1. Use amortization formula
2. VIP users get 0.5% discount
Output: Python code + usage exampleGeben Sie das einem Coding-Modell, und die Chancen auf etwas Brauchbares steigen, verglichen mit einem lockeren Prompt wie „write a loan calculator“.
Warum sollten Entwickler strengeres Englisch begrüßen, wenn sie schon über YAML stöhnen? Weil Prompts bereits YAML sind, nur eben unsichtbares, inkonsistentes YAML, das in Ihrem Kopf lebt. CNL macht diese Struktur explizit und gemeinsam nutzbar. Aus der sorgfältig abgestimmten Kreditrechner-Anfrage eines Entwicklers wird etwas, das dem ganzen Team gehört, statt als flüchtige Slack-Nachricht zu verschwinden.
Mehrdeutigkeit als Feature, nicht als Bug
Bevor wir tiefer einsteigen, sollten wir den stärksten Einwand offen zugeben: Mehrdeutigkeit ist nicht immer ein Problem. Manchmal ist sie der Sinn der Sache.
Lockere Prompts erlauben Modellen, Lösungen vorzuschlagen, die Menschen nie spezifiziert hätten. Wer zu eng einschränkt, würgt die Kreativität ab. Manche Entwickler behandeln KI-Assistenten schon jetzt wie chaotische Brainstorming-Partner, die gerade deshalb wertvoll sind, weil sie über die Linien hinausmalen.
Deshalb schlagen die meisten Forscher kontrollierte Sprache nicht als Ersatz für Vibe Coding vor, sondern als Ergänzung. Nutzen Sie freie Prompts für Prototypen und Erkundung. Holen Sie CNL dazu, sobald mehr auf dem Spiel steht: bei Produktivsystemen, regulatorischer Logik, Projekten über mehrere Teams. Mit anderen Worten: Die Vibes bleiben für die ersten Skizzen, die Disziplin kommt für die Baupläne dazu.
Context Engineering: der KI beibringen, was zählt
Prompt Engineering bekommt die Schlagzeilen, aber Context Engineering ist vielleicht genauso wichtig. Kontext ist alles, was das Modell „sieht“, bevor es Code erzeugt: das bisherige Gespräch, Ausschnitte aus dem Quellcode, Systemanweisungen, abgerufene Dokumente.
Hier spielen kontrollierte Spezifikationen ihre Stärke aus. Eine CNL-Anforderung ist mehr als ein besserer Prompt: Sie ist ein Artefakt, das sich wieder abrufen lässt. Weil die Sprache konsistent und strukturiert ist, können Sie Spezifikationen indexieren, per Vektorsuche finden und nur die relevanten Teile ans Modell geben.
Statt ein 20-seitiges Wiki in einen einzigen Prompt zu kippen, könnten Sie eine CNL-Spezifikation Anforderung für Anforderung zerlegen. Regel 1: Funktion A erzeugen. Regel 2: Funktion B erzeugen. Jedes Stück ist modular, nachvollziehbar und testbar.
Das ist keine Theorie. Forscher, die an CABERNET und RuleCNL arbeiten, haben gezeigt, wie sich strukturierte Anforderungen zerlegen und Schritt für Schritt ausführen lassen. Beim Vibe Coding hieße das: ein Assistent, der nicht einfach ein ganzes System halluziniert, sondern es Stück für Stück anhand einer Spezifikation zusammenbaut.
Erste Belege
Kontrollierte Sprachen sind nichts Neues. Airbus-Handbücher sind in einem vereinfachten englischen Dialekt geschrieben, damit Mechaniker in Toulouse und Tokio dasselbe darunter verstehen. Business Rule Engines (BREs) wie Corticon lassen Manager „If X then Y“-Regeln schreiben, die direkt zu Code kompiliert werden.
Neu ist die Verbindung mit LLMs. Ein aktuelles Paper, „WHEN PROMPT ENGINEERING MEETS SOFTWARE ENGINEERING: CNL-P AS NATURAL AND ROBUST ‘APIS’ FOR HUMAN-AI INTERACTION“, testete strukturierte Prompt-Formate an gängigen Programmieraufgaben. Die Ergebnisse waren dünn, ließen aber eine Tendenz erkennen: Kontrollierte Prompts verringerten Syntaxfehler um rund ein Drittel und brauchten weniger Korrekturrunden als gleichwertige freie Prompts. In einer Handvoll Studierendenprojekte berichteten Teams mit strukturierten Prompts, dass sie schneller zu funktionierenden Lösungen kamen. Das sind keine Daten auf Enterprise-Niveau. Es ist Labormaßstab, mit Prototypen. Aber die Richtung ist klar: Präzision hilft.
Warum das scheitern könnte (und warum das in Ordnung ist)
Das Tooling ist die erste Hürde. Ohne IDE-Unterstützung (Linter, Autovervollständigung, CI-Checks) fühlt sich CNL wie bürokratischer Overhead an. Die Forschungsprototypen sind kaum über den Status von Spielzeug hinaus. Niemand will Spezifikationen von Hand in Markdown schreiben, die dann nicht mehr zum Code passen.
Auch die soziale Dynamik ist heikel. „Das sind einfach JIRA-Tickets mit Größenwahn“, sagte ein Senior-Entwickler, der nicht genannt werden wollte. „Jetzt können PMs Englisch schreiben und funktionierenden Code erwarten? Das ist keine Befähigung, das ist Wunschdenken.“ Ein anderer Entwickler, der mit strukturierten Prompts experimentiert hat, sagte gegenüber Ars: „Die Hälfte des Teams liebte die Konsistenz. Die andere Hälfte hatte das Gefühl, wir hätten das Programmieren durch das Ausfüllen von Formularen ersetzt.“
Und vergessen Sie die Modelle selbst nicht. LLMs sind probabilistische Textgeneratoren. Sie vervollständigen Prompts so, dass es plausibel wirkt, nicht unbedingt so, dass es Regeln folgt. Selbst eine strukturierte Eingabe ignorieren sie manchmal. Solange Modelle nicht auf kontrollierte Sprachen feinabgestimmt sind oder starke Validatoren zwischen Eingabe und Ausgabe sitzen, bleibt die Einhaltung lückenhaft.
Schließlich ist da noch der Zielkonflikt mit der Kreativität. Unschärfe bringt manchmal elegante Lösungen hervor. Wer zu stark einschränkt, nimmt dem Modell womöglich die Fähigkeit, uns zu überraschen. Für Compliance-Systeme mag das in Ordnung sein, beim kreativen Programmieren ist es weniger willkommen.
Die Zukunft: Wer setzt darauf?
Die Arbeit läuft. Die Forschung verfeinert CNL-P und baut einen Konverter, der aus unsauberem Englisch kontrollierte Umformulierungen vorschlägt. Die akademischen Teams hinter CABERNET und RuleCNL veröffentlichen weiter Prototypen für Geschäftsregeln. Eine Handvoll Open-Source-Projekte auf GitHub experimentiert mit „Prompt-Lintern“, die vage Begriffe wie „fast“ oder „secure“ markieren.
Aber das Ökosystem ist dünn. Damit das Bedeutung bekommt, brauchen kontrollierte Prompts IDE-Plugins, versionierte Spezifikationen und CI-Integration. Sie müssen vollwertige Artefakte werden statt Kuriositäten aus der Forschung.
Der wahrscheinliche Weg führt über kleine Schritte. Teams könnten zunächst nur eine Klasse von Prompts in Vorlagen gießen, etwa für API-Endpunkte oder Datenvalidatoren, bevor sie kontrollierte Muster breiter einführen. Auch hybride Arbeitsabläufe sind plausibel: Vibes für Prototypen, dann die Spezifikationen in CNL festschreiben, sobald sich die Features stabilisiert haben.
Unterm Strich
Vibe Coding ist nicht tot, aber es hat eine Wartbarkeitskrise. Kontrollierte natürliche Sprache ist ein Lösungsvorschlag: weniger Improvisation, mehr Struktur. Selbst Skeptiker könnten sich auf diesen Tausch einlassen: strengeres Englisch für Code, der nicht verrottet.
Die Belege sind noch vorläufig, das Tooling ist unausgereift, und der soziale Widerstand ist real. Aber die Frage ist provokant: Was, wenn die Zukunft des Programmierens nicht nur in besseren KI-Modellen liegt, sondern in besserem Englisch?
Die Zukunft des Programmierens wird vielleicht nicht in Python oder Rust geschrieben. Vielleicht wird sie in einer Version des Englischen geschrieben, die diszipliniert genug ist, um sie wie Code zu behandeln, und locker genug, dass Menschen beim Mittagessen noch darüber streiten können.
Aus dem Englischen übersetzt: zum Originalbeitrag