CodeSpeak - le nouveau langage du créateur de Kotlin : dialoguer avec les LLM via des specs plutôt qu’en anglais

 (codespeak.dev)
42 points par GN⁺ 2026-03-14 | 4 commentaires | Partager sur WhatsApp
  • Langage de programmation de nouvelle génération basé sur les LLM, capable de réduire la taille d’une codebase de 5 à 10 fois
  • Au lieu d’écrire du code, le développeur rédige des specs concises, puis le code est généré automatiquement avec la commande codespeak build
  • Quand une spec change, le système convertit automatiquement le diff de la spec en diff de code et l’applique
  • Prend aussi en charge les projets mixtes où coexistent code écrit manuellement et code généré, avec une amélioration du taux de réussite des tests constatée sur des cas open source réels
  • Met l’accent sur l’ingénierie en équipe pour gérer des logiciels complexes, et vise un environnement de développement plus humain grâce à une maintenance centrée sur les specs

Présentation de CodeSpeak

  • CodeSpeak est un langage de programmation de nouvelle génération propulsé par les LLM, qui vise à réduire une codebase d’un facteur 5 à 10
    • D’après la description du site, l’efficacité est mise en avant par la formule « Shrink your codebase 5–10x »
  • Ce langage se présente comme un outil pour construire des systèmes de niveau production, conçu non pour de simples prototypes mais pour des projets de long terme
  • Il cible principalement les équipes d’ingénieurs qui développent des logiciels complexes, avec une orientation vers le développement collaboratif plutôt que vers un codage expérimental centré sur un développeur seul

Développement piloté par les specs

  • Le cœur de CodeSpeak repose sur la philosophie « Maintain Specs, Not Code »
    • Le développeur rédige des specs concises, puis le code est généré automatiquement avec la commande codespeak build
    • Quand une spec est modifiée, le système convertit automatiquement le diff de la spec en diff de code
  • Cette approche souligne qu’il est plus facile pour les humains de maintenir et gérer des specs que du code

Prise en charge des projets mixtes

  • CodeSpeak prend en charge les projets où coexistent code manuel et code généré
    • Un exemple présenté est un fork du dépôt MarkItDown de Microsoft
    • Un guide tutoriel est proposé pour traiter pas à pas les projets mixtes

Fonction code → spec (à venir)

  • CodeSpeak prépare une fonction de conversion de code existant en specs
    • Cela permettrait de remplacer une partie du code existant par des specs 5 à 10 fois plus compactes
    • Le projet insiste sur le fait que la maintenance des specs est plus adaptée aux humains que celle du code

Études de cas réelles

  • CodeSpeak a testé la conversion en specs de plusieurs codes de projets open source
    • Prise en charge des sous-titres WebVTT dans yt-dlp : 255 LOC → 38 LOC, réduction par 6,7, 37 tests ajoutés
    • Générateur de SSN italien dans Faker : 165 LOC → 21 LOC, réduction par 7,9, 13 tests ajoutés
    • Détection automatique d’encodage dans beautifulsoup4 : 826 LOC → 141 LOC, réduction par 5,9, 25 tests ajoutés
    • Convertisseur EML→Markdown dans markitdown : 139 LOC → 14 LOC, réduction par 9,9, 27 tests ajoutés
  • Dans chaque cas, le taux de réussite des tests a été maintenu ou amélioré, ce qui montre l’efficacité de l’approche fondée sur les specs

Résumé

  • CodeSpeak est un langage de programmation IA centré sur les specs, qui combine génération automatique de code et efficacité de maintenance
  • Ses principales caractéristiques sont la génération de code basée sur les LLM, la synchronisation spec-code et la prise en charge des projets mixtes
  • Des cas concrets montrent une réduction du code et une amélioration des tests, ce qui laisse entrevoir un gain de productivité pour l’ingénierie logicielle en équipe

À lire aussi

4 commentaires

 
roxie 2026-03-21

Est-ce que c’est juste du buzz de qualifier ça de langage, ou est-ce simplement l’époque qui veut ça ?
 
brainer 2026-03-14

Comme l’a dit Joel Spolsky lors d’une conférence à Yale, les tentatives de « générer un programme à partir d’une spécification (spec) » ont toujours échoué
Si une spécification est suffisamment détaillée pour définir complètement un programme, alors rédiger cette spécification est en soi aussi difficile que d’écrire le programme

Je suis d’accord sur le principe, mais ça me paraît évident : comme dans la démonstration de Gödel selon laquelle la perfection n’existe pas au départ, on dirait qu’on critique cette tentative en partant de l’hypothèse qu’un produit parfait pourrait exister.
 
halfenif 2026-03-14

Cela fait penser au MDD (Model Driven Dev.).
 
GN⁺ 2026-03-14
Réactions sur Hacker News

  • Comme l’a dit Joel Spolsky dans une conférence à Yale, les tentatives de « générer des programmes à partir d’une spec » ont toujours échoué
    si la spec est assez détaillée pour définir entièrement le programme, alors l’écrire est en soi presque aussi difficile que programmer directement
    Lien vers la conférence originale

    • La « génération de code à partir de spec » en 2007 n’a rien à voir avec ce que cela signifie aujourd’hui
      aujourd’hui, on peut générer un programme même avec un prompt incomplet, et il est utile d’étudier des façons plus systématiques de gérer les prompts
    • Le code devient désormais de plus en plus amorphe
      l’évolutivité se déplace de l’ajout de fonctionnalités vers la définition de contraintes de comportement et d’invariants structurels
    • En entreprise, on voit souvent des gens écrire de façon procédurale
      du genre « 1. demander des informations à l’utilisateur, 2. envoyer une requête HTTP, 3. signaler une erreur »,
      alors qu’à ce compte-là, écrire directement un script est bien plus rapide et déterministe
    • Blague sur la solution que le Joel d’avant l’IA n’avait pas envisagée : créer un « cristal de l’esprit » pour interpréter la spec

  • Ce n’est pas un nouveau langage, mais plutôt un workflow et un ensemble d’outils pour le développement basé sur les LLM
    au lieu du code, on maintient des fichiers de spec en Markdown, et codespeak modifie le code à partir des diff de spec
    l’avantage, c’est que les prompts sont versionnés avec le code ; l’inconvénient, c’est que la spec ne reflète pas tous les détails du code

    • Avec l’analogie que le C était lui aussi au fond un workflow de remplacement du développement en assembleur
    • On finira sans doute par aller vers un monde où les humains n’auront plus à toucher directement le code, mais on n’y est pas encore
      ils expérimentent avec un outil appelé codespeak takeover pour convertir le code en spec et y intégrer les prompts des sessions d’agent
      c’est présenté comme un passage d’un « mode sprint » de court terme à un « mode marathon » de long terme
      Article de blog lié
    • Le faire tourner comme un business semble peu réaliste
      l’idée est simple, donc n’importe qui peut la réimplémenter rapidement, et une version open source finira probablement par la remplacer
    • Si une petite correction de code, par exemple un bug off-by-one, oblige à modifier la spec, c’est inefficace
      proposition : une politique autorisant les « petits changements »
      dans l’ensemble, l’idée d’un compilateur de pseudocode incrémental est jugée intéressante
    • Cela paraît trop formel
      dans 5 ans, on n’écrira probablement plus le code comme ça, et une spec technique rédigée en anglais suffira sans doute

  • Cette approche ressemble plus à du tooling qui mappe une spec vers du code qu’à un langage
    mais les modèles sont non déterministes, donc une même spec peut produire un résultat différent à chaque fois
    une spec est fondamentalement un résumé avec beaucoup de perte d’information, ce qui rend la cohérence difficile à maintenir dans une grosse codebase
    ce que certains aimeraient voir, c’est un pipeline vérifiable allant d’une spec textuelle vers une spec formelle, puis vers le code

    • Contre-argument : si le résultat est toujours logiquement correct, peu importe que le code diffère
      ce qui compte, ce n’est pas le code lui-même, mais la cohérence du comportement produit
    • Mais même une spec formelle peut varier d’une fois à l’autre
      plus la spec est abstraite par rapport au code, plus elle autorise d’implémentations différentes ; la déterminisme n’est donc toujours pas garanti
    • Certains utilisent AGENTS.md, DESIGN.md et TECHNICAL-SPEC.md pour faire du développement informel piloté par des specs
      et considèrent que les tests automatisés devraient jouer le rôle de véritable spec
    • Doute exprimé sur l’idée que le modèle serait non déterministe
      avec une seed fixe, on devrait obtenir la même sortie pour la même entrée
    • Certains utilisent Kiro IDE comme générateur de specs
      là où Cursor ou Antigravity sont optimisés pour le « vibe coding » centré sur l’humain, Kiro est spécialisé dans le développement piloté par des specs centré sur les agents
      il utilise des formats structurés comme EARS et INCOSE, et génère des contrôles automatiques de cohérence ainsi que des tests basés sur les propriétés (PBT)
      quand la spec est solide, l’implémentation suit presque automatiquement
      plusieurs agents CLI sont exécutés en parallèle pour obtenir un résultat plus abouti

  • Le problème d’un langage de prompt formel n’est pas l’ambiguïté, mais le manque de compréhension contextuelle du modèle
    un même prompt peut donner des résultats différents selon le contexte
    formaliser les prompts ne sert à rien si le modèle comprend mal la codebase

    • Deux conseils reviennent souvent
      1. réinitialiser régulièrement le contexte
      2. fournir à l’agent des outils de style Unix, pour interagir avec lui via de simples commandes en pseudo-anglais
        les modèles étant optimisés pour le langage conversationnel, il vaut mieux ne pas écrire directement en langage formel et ne l’utiliser qu’en cas de besoin

  • Souhait exprimé : pouvoir simplement transmettre son intention à l’ordinateur de manière déterministe et formelle

  • Ce concept partirait d’une mauvaise compréhension de la structure interne des LLM
    selon des recherches récentes, les LLM disposent d’une étape de traitement distincte entre encodage et décodage,
    et après l’apprentissage, la langue elle-même n’est peut-être plus si importante
    Lien vers la recherche liée

    • CodeSpeak n’est pas fait pour les LLM, mais comme outil structurant pour les humains
      son objectif est d’aider les humains à exprimer clairement ce qu’ils veulent

  • Certains ne voient pas l’intérêt d’un tel outil
    il suffirait d’écrire directement une spec Markdown et de demander à l’agent de générer le code

  • Dans la section « Prerequisites » du tutoriel, il est indiqué qu’une clé API Anthropic est nécessaire
    c’est peut-être une mesure provisoire liée à la version alpha, mais on peut se demander pourquoi passer par une API
    injecter directement des prompts dans une session comme Claude Code semblerait suffire
    Lien de référence

  • Ce projet est jugé intéressant car très proche d’une spec de langage d’exécution pour LLM en cours de développement
    Mon projet AIL définit et exécute des chaînes de prompts en YAML
    l’idée centrale est d’avoir un « moteur de raffinement de prompt » qui transforme le langage naturel de l’utilisateur en commandes structurées
    par exemple, il analyse l’intention de l’utilisateur, la découpe en étapes, puis l’optimise selon les standards modernes de prompt engineering
    avec un tel intercepteur, un flux du type « transforme ce que je viens de dire en format CodeSpeak » deviendrait possible
    l’idée est jugée vraiment excellente et mérite d’être explorée en profondeur