CodeSpeak : le créateur de Kotlin parie que dans cinq ans, les développeurs n'écriront plus de code
CodeSpeak : le créateur de Kotlin parie que dans cinq ans, les développeurs n'écriront plus de code mais des spécifications en anglais et les LLM feront le reste
Il a donné naissance à Kotlin, le langage qui a conquis le développement Android et séduit sept millions de développeurs dans le monde. Andrey Breslav, qui a piloté la conception du langage chez JetBrains de 2010 à 2020, revient avec une ambition d'une tout autre nature : non plus simplifier Java, mais repenser de fond en comble la relation entre les humains et la machine à l'ère des grands modèles de langage. Son nouveau projet, CodeSpeak, se présente comme un langage de programmation de nouvelle génération dans lequel le développeur n'écrit plus de code, mais des spécifications en anglais structuré. Un LLM se charge ensuite de générer, maintenir et tester le code correspondant. L'accueil sur les forumes spécialisés oscille entre fascination et scepticisme acéré.
Pour comprendre CodeSpeak, il faut comprendre pourquoi Kotlin a existé. Entre 2004 et 2010, Java stagnait : Java 6 n'apportait aucune évolution syntaxique notable, les lambdas n'arriveraient qu'en 2014 avec Java 8. Les développeurs avaient besoin de fonctionnalités modernes — sécurité par rapport aux valeurs nulles, programmation fonctionnelle, syntaxe concise. Kotlin a comblé ce vide.
Breslav applique aujourd'hui la même grille d'analyse à l'ère de l'IA. Le problème n'est plus la verbosité de Java, c'est la masse de code boilerplate que les équipes doivent produire, relire et maintenir alors que les LLM sont désormais capables de le générer automatiquement. CodeSpeak n'est ni un langage formel classique ni du simple prompting : il est conçu pour les ingénieurs, pas pour les utilisateurs occasionnels, et vise à réduire le code applicatif typique d'environ dix fois. Ce qui reste constitue « l'essence du génie logiciel » — uniquement ce que l'humain sait de façon unique sur ce qui doit se passer, parce que « tout le reste, la machine le sait aussi bien ».
Le principe : la spécification comme source de vérité
Le cœur du projet repose sur un renversement conceptuel radical. Dans le workflow traditionnel, le code est la source de vérité ; la documentation et les spécifications en sont des dérivés souvent obsolètes. CodeSpeak inverse ce rapport : une spec décrit une partie logiquement autonome du système, et les fichiers source correspondants forment sa portée. On dit que ce code est géré par la spec correspondante : il sera généré, mis à jour et maintenu en fonction des modifications apportées à la spec.
Concrètement, les specs sont rédigées dans des fichiers Markdown portant l'extension .cs.md, avec une syntaxe délibérément sobre. Pour ajouter un convertisseur de fichiers .eml à la bibliothèque open source MarkItDown de Microsoft, il suffit d'écrire une quinzaine de lignes décrivant le format accepté, la structure de sortie attendue et les règles de décodage. CodeSpeak crée ensuite les fichiers nécessaires, les intègre dans les fichiers existants autorisés et génère des fichiers de tests.
Les résultats affichés sur le site sont éloquents. Sur quatre projets open source réels (le téléchargeur de vidéos yt-dlp, la bibliothèque Faker, BeautifulSoup4 et MarkItDown), le facteur de réduction entre lignes de code et lignes de spec varie de 5,9 à 9,9, avec dans tous les cas un nombre de tests qui augmente après la migration. La version 0.3.4, publiée début mars 2026, introduit la modularité : les specs peuvent désormais s'importer mutuellement, et CodeSpeak construit dans l'ordre des dépendances, les dépendances en premier, puis les specs qui les utilisent. Seules les specs modifiées sont reconstruites.
Une architecture orientée équipe, pas vibe-coding
Breslav insiste sur un positionnement qui distingue CodeSpeak de la vague actuelle des outils de « vibe coding » : la cible est celle des ingénieurs qui construisent des logiciels complexes, pas les « vibe-coders » ni les solopreneurs. La communication au sein d'une équipe est explicitement identifiée comme un enjeu central.
L'outil se déploie en mode « mixte » (mixed mode), ce qui signifie qu'il peut coexister avec une base de code existante. Seuls les fichiers explicitement déclarés dans codespeak.json sont gérés par l'outil ; les autres fichiers du projet restent intouchés à moins d'être inscrits sur une liste blanche. Cette granularité de contrôle répond à un souci de traçabilité : quand CodeSpeak modifie un fichier qui n'est pas dans le périmètre d'une spec donnée (un pyproject.toml, par exemple) il le signale explicitement, avec plusieurs options pour gérer ce cas à l'avenir.
L'outillage repose entièrement sur Claude d'Anthropic (modèle Opus 4.6 recommandé pour les projets complexes en mode mixte), via une clé API fournie par l'utilisateur. CodeSpeak est donc, pour l'heure, un orchestrateur sophistiqué qui traduit des diffs de specs en instructions pour un agent Claude, exécute les tests, et itère jusqu'à ce que le résultat soit valide.
L'accueil mitigé des forums spécialisés
Les discussions sur les forums spécialisés, où un fil a été lancé sous le titre provocateur « le nouveau langage du créateur de Kotlin : une façon formelle de parler aux LLM plutôt qu'en anglais », concentre les critiques les plus substantielles du domaine.
Première objection de fond : les modèles ne sont pas déterministes ; chaque nouvelle tentative de reconstruction produirait vraisemblablement un code différent. Les modèles évoluent rapidement : la version de Codex ou Claude du mois dernier génèrerait probablement un code différent de celle d'aujourd'hui. Les spécifications textuelles sont toujours sous-spécifiées, sujettes à des pertes d'information et tendent à négliger une grande quantité de détails que le code doit rendre concrets.
Deuxième objection, plus philosophique : si les LLM permettent précisément d'exprimer ses idées en anglais naturel, pourquoi créer un nouveau langage formel pour leur parler ? Un utilisateur formule la contradiction : « Nous avons créé les LLM pour que vous puissiez exprimer vos idées en anglais et n'ayez plus besoin de coder. Aussi, l'anglais est vraiment trop verbeux et imprécis pour coder, alors nous avons développé un langage de programmation à la place. » Un autre renchérit avec une spirale vertigineuse : nous avons créé des langages de programmation pour diriger les machines, puis des LLM pour utiliser l'anglais à cette fin, et maintenant un langage de programmation pour diriger les LLM.
Troisième objection, plus technique : selon plusieurs intervenants, le vrai goulot d'étranglement dans la construction d'agents n'est pas l'ambiguïté du prompt, mais la compréhension du contexte par le modèle. Le même prompt précis peut produire des résultats radicalement différents selon ce qui se trouve dans la fenêtre de contexte. Formaliser le prompt n'aide pas si le modèle construit une représentation interne incorrecte de la base de code.
Certains commentateurs jugent également que CodeSpeak n'est pas vraiment un langage au sens strict, mais plutôt un workflow outillé autour de fichiers Markdown structurés. Comme le résume un contributeur, il ne s'agit pas d'un nouveau langage, mais d'un flux de travail alternatif pour le développement assisté par LLM, avec un outil qui l'implémente : au lieu d'indiquer directement à un agent comment modifier le code, on conserve des fichiers de spec en Markdown décrivant ce que le code fait, puis l'outil exécute un diff sur ces fichiers et demande à l'agent d'effectuer les changements correspondants.
Une idée ancienne sous un nouveau capot ?
Les plus historicistes des commentateurs font remonter la généalogie de l'idée. La literate programming de Donald Knuth, les langages Gherkin pour le BDD (Behavior-Driven Development), COBOL lui-même, toutes ces tentatives de rapprocher la description du problème de son implémentation refont surface dans les fils de discussion.
Breslav a répondu directement au problème de la dérive entre spécification et implémentation, en indiquant que CodeSpeak inclura des outils pour convertir le code existant en spécifications, permettant aux développeurs de synchroniser les modifications dans les deux sens. La fonctionnalité, intitulée codespeak takeover, est partiellement disponible en alpha depuis fin février 2026.
Ce qui demeure incontestable, c'est le poids de la trajectoire de Breslav. Il est le créateur du langage Kotlin et a dirigé son développement chez JetBrains depuis ses débuts jusqu'à son adoption par des millions d'utilisateurs dans le monde. Quand quelqu'un de cette stature parie sur une idée, même controversée, l'industrie a intérêt à observer attentivement. Kotlin lui-même semblait inutile à beaucoup en 2011 (Java était omniprésent, Scala existait déjà). Il est aujourd'hui le langage officiel d'Android.
CodeSpeak est en alpha publique, disponible via uv tool install codespeak-cli, avec un modèle BYOK (Bring Your Own Key) qui nécessite une clé API Anthropic. La feuille de route annoncée prévoit la spécification d'interfaces entre modules, la détection des erreurs quand un import ne fournit pas ce qu'on en attend, et la génération de modules suffisamment isolés pour être réutilisables dans d'autres projets.
Sources : CodeSpeak, Université de Cambridge
Le non-déterminisme des LLM est-il un obstacle rédhibitoire à l'idée que la spécification puisse être la source de vérité, ou les suites de tests suffisent-elles à garantir la cohérence du code généré quelle que soit la version du modèle ?
Répondre avec citation
Partager