CodeSpeak – die neue Sprache des Kotlin-Erfinders: Mit LLMs per Spezifikation statt auf Englisch sprechen

• Eine Programmiersprache der nächsten Generation auf Basis von LLMs, die eine 5- bis 10-fache Verkleinerung der Codebasis ermöglichen soll
• Entwickler schreiben statt Code eine knappe Spezifikation (Spec), und mit dem Befehl codespeak build wird der Code automatisch erzeugt
• Wenn sich die Spezifikation ändert, wandelt das System die Diffs der Spezifikation in Code-Diffs um und übernimmt sie automatisch
• Unterstützt auch gemischte Projekte mit handgeschriebenem und generiertem Code; in realen Open-Source-Beispielen wurde eine Verbesserung der Test-Erfolgsquote bestätigt
• Fokus auf Engineering in Teams, die komplexe Software entwickeln, mit dem Ziel einer menschenfreundlichen Entwicklungsumgebung durch spezifikationszentrierte Wartung

---

Überblick über CodeSpeak

• CodeSpeak ist eine LLM-gestützte Programmiersprache der nächsten Generation, die darauf abzielt, die Codebasis um das 5- bis 10-Fache zu verkleinern
  • Laut Website wird die Effizienz mit dem Slogan „Shrink your codebase 5–10x“ hervorgehoben
• Die Sprache ist als Werkzeug für den Aufbau produktionstauglicher Systeme gedacht und wurde nicht für einfache Prototypen, sondern für langfristige Projekte konzipiert
• Als Hauptnutzer sind Engineering-Teams, die komplexe Software entwickeln, vorgesehen; angestrebt wird kollaborative Entwicklung statt experimentelles Coding für Einzelentwickler

Spezifikationsbasierter Entwicklungsansatz

• Der Kern von CodeSpeak ist die Philosophie „Maintain Specs, Not Code“
  • Entwickler schreiben eine knappe Spezifikation (Spec), und mit dem Befehl codespeak build wird der Code automatisch erzeugt
  • Wird die Spezifikation geändert, konvertiert das System Änderungen (Diffs) in der Spezifikation automatisch in Code-Änderungen (Diffs)
• Dieser Ansatz betont, dass das Pflegen und Verwalten von Spezifikationen für Menschen einfacher ist als das Verwalten von Code

Unterstützung für gemischte Projekte

• CodeSpeak unterstützt Projekte, in denen bestehender handgeschriebener und generierter Code nebeneinander bestehen
  • Als Beispiel wird ein geforktes Repository von Microsofts MarkItDown vorgestellt
  • Es gibt eine Tutorial-Anleitung, die den Umgang mit gemischten Projekten Schritt für Schritt erklärt

Code → Spezifikation-Konvertierung (geplant)

• CodeSpeak bereitet eine Funktion zur Umwandlung bestehenden Codes in Spezifikationen vor
  • Dadurch könnten Teile bestehenden Codes durch 5- bis 10-mal kleinere Spezifikationen ersetzt werden
  • Hervorgehoben wird, dass die Pflege von Spezifikationen menschenfreundlicher ist als die von Code

Praxisbeispiele (Case Studies)

• CodeSpeak hat den Code mehrerer Open-Source-Projekte in Spezifikationen umgewandelt und getestet
  • WebVTT-Untertitelunterstützung in yt-dlp: 255 LOC → 38 LOC, 6,7-fache Verkleinerung, 37 Tests hinzugefügt
  • Italienischer SSN-Generator in Faker: 165 LOC → 21 LOC, 7,9-fache Verkleinerung, 13 Tests hinzugefügt
  • Automatische Encoding-Erkennung in beautifulsoup4: 826 LOC → 141 LOC, 5,9-fache Verkleinerung, 25 Tests hinzugefügt
  • EML→Markdown-Konverter in markitdown: 139 LOC → 14 LOC, 9,9-fache Verkleinerung, 27 Tests hinzugefügt
• In allen Fällen blieb die Test-Erfolgsquote erhalten oder verbesserte sich, was die Praxistauglichkeit des spezifikationsbasierten Ansatzes zeigt

Zusammenfassung

• CodeSpeak ist eine KI-Programmiersprache mit Fokus auf Spezifikationen, die automatische Codegenerierung mit effizienterer Wartung verbindet
• Zu den wichtigsten Merkmalen gehören LLM-basierte Codegenerierung, Synchronisierung von Spezifikation und Code sowie Unterstützung für gemischte Projekte
• Praxisbeispiele belegen Code-Reduktion und bessere Tests und deuten auf Produktivitätssteigerungen im Software-Engineering für Teams hin

[roxie]

Ob man das überhaupt noch eine Sprache nennen sollte, nur um Aufmerksamkeit zu erzeugen, oder ob wir inzwischen einfach in so einer Zeit leben.

[brainer]

Wie Joel Spolsky in einem Vortrag an der Yale University sagte, sind Versuche, „Programme aus Spezifikationen zu erzeugen“, bisher immer gescheitert.
Wenn eine Spezifikation so detailliert ist, dass sie ein Programm vollständig definiert, dann ist das Schreiben dieser Spezifikation selbst fast genauso schwierig wie das Programmieren des Programms.

Dem stimme ich grundsätzlich zu, aber es wirkt auch selbstverständlich – ähnlich wie Gödels Beweis, dass es von vornherein keine Vollständigkeit gibt. Die Kritik scheint also von der Annahme auszugehen, dass es ein vollständiges Produkt geben könne.

[halfenif]

Das erinnert an MDD (Model Driven Dev.).

[GN⁺]

Hacker-News-Kommentare

• Wie Joel Spolsky in einem Yale-Vortrag sagte, sind Versuche, „Programme aus Spezifikationen zu erzeugen“, bisher immer gescheitert
  Wenn eine Spezifikation so detailliert ist, dass sie ein Programm vollständig definiert, ist das Schreiben dieser Spezifikation selbst fast so schwierig wie das Programmieren
  Link zum Originalvortrag

  • Die „spezifikationsbasierte Codegenerierung“ von 2007 und die heutige Bedeutung sind völlig unterschiedlich
    Heute kann man selbst mit unvollständigen Prompts Programme erzeugen, und Forschung zum systematischen Umgang mit Prompts ist wertvoll
  • Code wird inzwischen immer amorpher
    Die Skalierbarkeit verlagert sich von der Erweiterung um Funktionen hin zur Definition von Verhaltensbeschränkungen und strukturellen Invarianten
  • Im Unternehmen sieht man oft, dass Leute prozedural schreiben
    etwa so: „1. Nutzer zur Eingabe von Informationen auffordern, 2. eine HTTP-Anfrage senden, 3. bei einem Fehler Meldung erstatten“,
    aber dann ist es meiner Meinung nach viel schneller und deterministischer, einfach ein Skript zu schreiben
  • Als Scherz wird eine Lösung genannt, auf die Joel vor der AI-Ära nicht gekommen wäre: Man müsse einfach einen „Kristall des Geistes“ erschaffen, der die Spezifikation interpretiert

• Das ist keine neue Sprache, sondern eher ein Workflow und Tooling für LLM-basierte Entwicklung
  Statt Code pflegt man Markdown-Spezifikationsdateien, und codespeak ändert den Code auf Basis der Diff der Spezifikation
  Der Vorteil ist, dass Prompts zusammen mit dem Code versioniert werden; der Nachteil ist, dass die Spezifikation nicht alle Details des Codes abbilden kann

  • Als Analogie wird ergänzt, dass auch C letztlich ein Ersatz-Workflow für die Entwicklung in Assembler war
  • Am Ende wird die Welt wohl dahin gehen, dass Menschen Code nicht mehr direkt anfassen müssen, aber noch sind wir nicht so weit
    Mit dem Tool codespeak takeover wird experimentiert, Code in Spezifikationen umzuwandeln und dabei Prompts aus Agent-Sessions zu berücksichtigen
    Beschrieben wird das als Wechsel vom kurzfristigen „Sprint-Modus“ in einen langfristigen „Marathon-Modus“
    Zugehöriger Bloglink
  • Es wird bezweifelt, dass sich das als Business betreiben lässt
    Die Idee sei so einfach, dass sie jeder schnell nachbauen könne, und eine Open-Source-Version werde sie bald ersetzen
  • Wenn man für kleine Codekorrekturen, etwa einen Off-by-one-Bug, erst die Spezifikation ändern muss, ist das ineffizient
    Vorgeschlagen wird eine Richtlinie, die „kleine Änderungen“ erlaubt
    Insgesamt ist das Konzept eines inkrementellen Pseudocode-Compilers interessant
  • Es wirkt zu formal
    In fünf Jahren werde man Code wahrscheinlich nicht mehr auf diese Weise schreiben, und technische Spezifikationen auf Englisch-Niveau dürften ausreichen

• Dieser Ansatz ist weniger eine Sprache als vielmehr Tooling, das Spezifikationen auf Code abbildet
  Modelle sind jedoch nicht deterministisch, daher kann dieselbe Spezifikation jedes Mal ein anderes Ergebnis liefern
  Spezifikationen sind ihrem Wesen nach stark verlustbehaftete Zusammenfassungen, deshalb ist es in großen Codebasen schwer, Konsistenz zu wahren
  Wünschenswert wäre eine überprüfbare Pipeline von Textspezifikation → formale Spezifikation → Code

  • Dagegen wird eingewandt, dass es egal ist, wenn der Code unterschiedlich ausfällt, solange das Ergebnis logisch immer korrekt ist
    Entscheidend ist weniger der Code selbst als die Konsistenz des Verhaltens
  • Aber auch formale Spezifikationen können jedes Mal anders ausfallen
    Je abstrakter die Spezifikation im Vergleich zum Code ist, desto mehr unterschiedliche Implementierungen sind möglich, daher bleibt Determinismus weiterhin unerreichbar
  • Ich arbeite mit AGENTS.md, DESIGN.md und TECHNICAL-SPEC.md und betreibe informelle spezifikationsbasierte Entwicklung
    Ich finde, automatisierte Tests sollten die eigentliche Rolle der Spezifikation übernehmen
  • Die Behauptung, Modelle seien nicht deterministisch, wird infrage gestellt
    Mit festem Seed könne man bei gleicher Eingabe die gleiche Ausgabe erhalten
  • Ich nutze Kiro IDE als Spezifikationsgenerator
    Cursor und Antigravity sind für menschenzentriertes „vibe coding“ optimiert, Kiro dagegen ist auf agentenzentrierte spezifikationsbasierte Entwicklung spezialisiert
    Es verwendet strukturierte Formate wie EARS und INCOSE und erzeugt automatische Konsistenzprüfungen sowie Property-Based Testing (PBT)
    Wenn die Spezifikation solide ist, folgt die Implementierung fast automatisch
    Ich lasse mehrere CLI-Agenten parallel laufen und erhalte dadurch sehr ausgereifte Ergebnisse

• Das Problem einer formalen Prompt-Sprache ist nicht Mehrdeutigkeit, sondern das unzureichende Kontextverständnis des Modells
  Derselbe Prompt kann je nach Kontext zu anderen Ergebnissen führen
  Selbst wenn man Prompts formalisiert, bringt das nichts, wenn das Modell die Codebasis falsch versteht

  • Zwei Ratschläge hört man häufig
    1. den Kontext regelmäßig zurücksetzen
    2. dem Agenten Unix-artige Werkzeuge geben, damit er über einfache pseudoenglische Befehle interagieren kann
       Modelle sind auf dialogische Sprache optimiert, daher ist es wohl besser, keine formale Sprache direkt zu schreiben, sondern sie nur bei Bedarf einzusetzen

• Es wird einfach der Wunsch geäußert, Absichten dem Computer auf deterministische und formale Weise mitteilen zu können

• Dieses Konzept geht von einem falschen Verständnis der inneren Struktur von LLMs aus
  Jüngere Forschung deutet darauf hin, dass LLMs zwischen Enkodierung und Dekodierung eine eigene Verarbeitungsstufe haben,
  und dass Sprache nach dem Training selbst gar nicht mehr so wichtig sein könnte
  Link zur betreffenden Studie

  • CodeSpeak ist nicht für LLMs gedacht, sondern ein Strukturierungswerkzeug für Menschen
    Ziel ist es, Menschen dabei zu helfen, klar auszudrücken, was sie wollen

• Ich weiß nicht, ob man so ein Werkzeug überhaupt braucht
  Man kann einfach Markdown-Spezifikationen direkt schreiben und dem Agenten sagen, er solle daraus Code erzeugen

• In den „Prerequisites“ des Tutorials steht, dass ein Anthropic-API-Schlüssel nötig ist
  Vielleicht ist das in der Alpha-Version nur eine vorübergehende Maßnahme, aber ich frage mich, warum man überhaupt die API braucht
  Es müsste doch reichen, Prompts direkt in eine Session wie Claude Code einzuschleusen
  Referenzlink

• Interessant ist, dass dieses Projekt meiner laufenden LLM-Executor-Sprachspezifikation sehr ähnelt
  Mein Projekt AIL definiert und führt Prompt-Ketten auf YAML-Basis aus
  Der Kern ist eine „Prompt-Refinement-Engine“, die natürliche Sprache von Nutzern in strukturierte Befehle umwandelt
  Zum Beispiel analysiert sie die Absicht des Nutzers, zerlegt sie in einzelne Schritte und optimiert sie gemäß modernen Prompt-Engineering-Standards
  Mit so einem Interceptor wäre ein Ablauf wie „Wandle das, was ich gerade gesagt habe, ins CodeSpeak-Format um“ möglich
  Das ist wirklich eine großartige Idee, die ich unbedingt genauer erforschen will