Le code qui ne s'écrit pas : CodeSpeak et la révolution des spécifications

Il y a des noms qui, dans le monde de la programmation, portent un poids spécifique. Andrey Breslav est l'un d'entre eux. Si aujourd'hui des millions de développeurs Android écrivent du code en Kotlin plutôt qu'en Java, c'est en grande partie grâce à lui : Breslav est le concepteur principal du langage que JetBrains a lancé en 2011 et que Google a officiellement adopté comme langage préféré pour Android en 2017, lors du Google I/O qui a changé l'écosystème mobile pour toujours. Ce n'est pas un universitaire qui théorise depuis une chaire : c'est l'un de ceux qui ont construit des outils utilisés chaque jour par des centaines de milliers de personnes dans le monde réel, avec tous les compromis, les bugs de production et les pressions que cela comporte.

Ce préambule n'est pas un hommage gratuit. Il sert à comprendre pourquoi son nouveau projet, CodeSpeak, mérite une attention bien au-delà des frontières des habituels aperçus de langages expérimentaux qui prolifèrent sur GitHub. Quand Breslav dit vouloir repenser la façon dont les êtres humains interagissent avec le code à l'ère des agents IA, il le fait avec le bagage de celui qui a déjà parcouru une fois ce chemin et sait où se cachent les pièges. Comme il l'a raconté à Gergely Orosz dans le podcast du Pragmatic Engineer, la leçon la plus profonde de Kotlin ne concerne pas la syntaxe ou le système de types, mais l'interopérabilité : un nouveau langage qui ne parvient pas à cohabiter pacifiquement avec ce qui existe déjà est voué à rester une expérience. C'est un principe qu'il a transféré directement dans CodeSpeak.

Le projet est en Alpha Preview, un détail qu'il convient de garder à l'esprit tout au long de la lecture, et il est construit autour d'une idée qui, énoncée en une ligne, sonne presque comme une provocation : et si nous arrêtions de maintenir le code et commencions à maintenir les spécifications ?

Spécifications, pas code : un changement de paradigme

Pour comprendre ce que propose CodeSpeak, il faut d'abord faire un pas en arrière et regarder le problème qu'il tente de résoudre. Quiconque a travaillé sur un projet logiciel de complexité moyenne connaît cette sensation : le code croît. Il croît quand on ajoute des fonctionnalités, il croît quand on corrige des bugs, il croît quand de nouveaux développeurs arrivent et interprètent les spécifications de manière légèrement différente de ceux qui les ont précédés. Avec l'arrivée des agents IA qui génèrent des milliers de lignes en quelques secondes, cette croissance risque de devenir incontrôlable. Non pas parce que le code généré est nécessairement faux, mais parce que plus personne ne parvient à le garder entièrement en tête.

Le terrain sur lequel s'implante CodeSpeak n'est pas neutre. En février 2025, Andrej Karpathy, cofondateur d'OpenAI et ancien directeur de l'IA chez Tesla, a inventé l'expression "vibe coding" pour décrire une pratique déjà très répandue : donner des instructions en langage naturel à un agent IA et accepter le code généré sans vraiment le lire, en se fiant à l'instinct que "ça marche". Le post original sur X a recueilli des millions de vues en quelques jours, et l'étiquette est même entrée dans le dictionnaire Merriam-Webster dès mars de la même année, une vitesse qui en dit long sur la réalité du phénomène. CodeSpeak est né exactement comme une réponse structurée à cette dérive : il ne nie pas que les LLM puissent écrire du code utile, mais soutient que laisser les agents libres de générer sans contraintes formelles produit des bases de code que plus personne ne comprend vraiment.

CodeSpeak propose de déplacer le curseur : au lieu d'écrire et de maintenir le code d'implémentation, l'équipe maintient des fichiers de spécification, des documents compacts, lisibles par un être humain, écrits dans un Markdown structuré avec sa propre syntaxe. C'est ensuite le système qui se charge de traduire ces spécifications en code fonctionnel, en utilisant un modèle de langage (actuellement Claude d'Anthropic, ce qui explique l'exigence d'une clé API) comme moteur de génération.

L'analogie la plus utile, pour ceux qui n'écrivent pas de code, est celle des dessins techniques en architecture. Un architecte ne construit pas l'édifice brique par brique : il dessine les plans, spécifie les matériaux, définit les proportions et les charges. Les ouvriers, ou dans ce cas, le LLM, se chargent de l'exécution concrète. Quand l'architecte veut modifier la disposition d'une pièce, il ne démolit pas et ne reconstruit pas : il met à jour les plans, et le chantier s'adapte. CodeSpeak fonctionne exactement ainsi : on modifie la spécification, on lance codespeak build, et le code est mis à jour en conséquence.

Cette approche s'inscrit dans un débat plus large qui, dans le monde du développement logiciel, porte divers noms : spec-driven development, intent-based programming, ou plus généralement l'idée que le prochain niveau d'abstraction ne sont pas de nouveaux langages de programmation au sens traditionnel, mais de nouvelles façons de communiquer l'intention aux agents IA. La différence par rapport au simple "prompt engineering", le fait de donner des instructions à un chatbot, est que CodeSpeak introduit de la structure, du versionnement et de la testabilité. Les spécifications vivent dans un dépôt Git, sont tracées comme n'importe quel autre artefact de code, et leur effet est mesuré à travers les suites de tests existantes. Ce n'est pas du vibe coding : c'est de l'ingénierie logicielle avec un niveau d'abstraction plus élevé. Image tirée de codespeak.dev

Comment ça marche : de la CLI au takeover

Techniquement, CodeSpeak s'installe avec une seule commande de terminal, uv tool install codespeak-cli, et nécessite une clé API Anthropic que l'utilisateur fournit (le modèle est BYOK, Bring Your Own Key). De là, le flux de travail s'articule autour de trois modes principaux, pensés pour des scénarios différents.

Le mode le plus simple est le mode à partir de zéro (greenfield) : on initialise un projet CodeSpeak, on écrit les spécifications dans des fichiers Markdown avec l'extension .cs.md, on lance codespeak build et le système génère le code Python correspondant, exécute les tests, et signale si tout fonctionne. Une spécification pour une application CLI de gestion de notes pourrait occuper littéralement dix lignes de texte lisible, et produire une application fonctionnelle complète avec commandes, gestion du stockage et interface terminal.

Le mode le plus intéressant, et celui qui a le plus d'implications pratiques pour ceux qui travaillent sur des projets existants, est le mixed mode. CodeSpeak ne demande pas de jeter le code qui existe déjà : il peut cohabiter avec lui. On l'initialise avec codespeak init --mixed, et dès lors le projet devient hybride : certaines parties restent écrites à la main par les développeurs, d'autres sont gérées par les spécifications. L'LLM "voit" les deux parties pendant la génération, et peut utiliser le code manuel comme contexte pour implémenter correctement les spécifications. C'est un compromis pragmatique qui rappelle, non par hasard, le choix de Kotlin de garantir une interopérabilité complète avec Java dès le premier jour.

Le troisième scénario, introduit récemment avec la commande codespeak takeover, est peut-être le plus suggestif : étant donné un fichier de code existant, même hérité, même écrit il y a des années par quelqu'un d'autre, CodeSpeak lit la source et en extrait automatiquement une spécification compacte. Dès lors, pour modifier ce composant, on ne touche plus au code Python (ou à tout autre langage) : on modifie la spécification, et on relance le build. Dans le post officiel du blog illustrant cette fonctionnalité, l'équipe a utilisé comme cobaye le projet open source MarkItDown de Microsoft, un convertisseur de documents en Markdown, en prenant le fichier responsable de la conversion des fichiers .msg d'Outlook, en extrayant une spécification de quelques dizaines de lignes, puis en utilisant cette spécification pour corriger un bug réel signalé sur GitHub. Le tout sans toucher une seule ligne de Python. La modification de la spécification, pour ajouter le support des champs Cc, Bcc, Date et des pièces jointes manquantes, était de 23 lignes ; le code généré qui en a résulté était de 221 lignes. Un rapport d'environ 10 pour 1.

Modularité : quand les spécifications deviennent un système

Un langage qui ne fonctionne que pour de petits projets est une expérience de laboratoire. Pour devenir un outil professionnel, il doit passer à l'échelle. Et c'est là qu'entrent en jeu les fonctionnalités de modularité que l'équipe a publiées le 9 mars 2026 avec la version 0.3.4 : les spec dependencies et les managed files.

L'idée des spec dependencies est analogue à celle des modules dans le code traditionnel : une spécification peut déclarer dépendre d'une autre via une simple directive dans le frontmatter du fichier Markdown. Si la spécification de l'interface en ligne de commande d'une application dépend de la spécification de la couche de stockage des données, CodeSpeak construit d'abord la couche de stockage, puis l'interface, garantissant que la seconde puisse utiliser correctement ce que la première fournit. Et si l'on modifie seulement la spécification du stockage (en changeant, par exemple, le backend de JSON à SQLite avec une seule ligne de texte), CodeSpeak ne reconstruit que cette partie, sans toucher au reste.

Les managed files sont quant à eux un mécanisme de gouvernance : chaque spécification "sait" quels fichiers de code sont sous sa responsabilité. Quand, lors d'un build, CodeSpeak a besoin de modifier un fichier qui n'appartient pas à la spécification courante, par exemple le fichier de configuration des dépendances du projet, il le fait, mais avertit explicitement le développeur. Toute la logique rappelle la distinction entre propriété et accès dans les systèmes de contrôle d'accès : chaque spécification a son domaine, et les invasions de terrain sont signalées, non tolérées silencieusement. Pour des équipes travaillant sur des bases de code volumineuses et complexes, c'est une garantie non négligeable contre les effets secondaires indésirables des modifications. Image tirée de github.com

Les chiffres : à quel point le code est-il réellement réduit ?

Les études de cas publiées sur le site officiel sont l'élément le plus concret et vérifiable de toute la proposition. L'équipe a pris quatre projets open source réels, et non des exemples de jouets construits ad hoc, et a généré les spécifications correspondantes pour des portions significatives de leur code, mesurant la réduction en termes de lignes.

Pour yt-dlp, le célèbre téléchargeur de vidéos, le composant de gestion des sous-titres WebVTT est passé de 255 lignes de code à 38 lignes de spécification, avec un facteur de réduction de 6,7 fois. Pour Faker, la bibliothèque Python de génération de données fictives, le générateur de codes fiscaux italiens est passé de 165 à 21 lignes (7,9 fois). Pour BeautifulSoup4, la bibliothèque d'analyse HTML, le module de détection automatique de l'encodage est le cas le plus impressionnant : 826 lignes de code réduites à 141 de spécification, facteur 5,9. Et pour MarkItDown, le convertisseur de Microsoft déjà cité, le module EML est passé de 139 à 14 lignes, avec un facteur de 9,9, soit presque 10 fois moins.

La donnée qui frappe plus que les chiffres absolus, cependant, est celle relative aux tests. Dans les quatre cas, la suite de tests a non seulement continué à passer après la régénération du code, mais a vu le nombre de tests réussis augmenter : 37 tests ajoutés pour yt-dlp, 13 pour Faker, 25 pour BeautifulSoup4, 27 pour MarkItDown. La réduction du code n'est pas de la cosmétique, il ne s'agit pas de compresser la source en éliminant commentaires et espaces vides, mais d'éliminer la redondance conceptuelle en laissant l'LLM s'occuper des détails d'implémentation qui sont, comme les appelle Breslav, "évidents pour les machines". Ce qui reste dans la spécification est uniquement ce qui est spécifique au domaine : les règles métier, les choix architecturaux, les cas limites.

Ceci dit, il est honnête de signaler une limite méthodologique : ces tests ont été menés par l'équipe même de CodeSpeak sur des portions sélectionnées de projets open source. Il ne s'agit pas de benchmarks indépendants sur des bases de code arbitraires. La question de savoir comment le système se comporte sur du code particulièrement complexe, avec des dépendances circulaires ou une logique distribuée entre de nombreux fichiers, reste pour l'instant sans réponse documentée.

Plus humains ou moins humains ?

Il y a une tentation récurrente, quand on parle d'outils d'IA pour le développement logiciel, de tomber dans l'un des deux pièges symétriques : soit le triomphalisme ("l'IA fera tout, les programmeurs sont obsolètes"), soit le déni ("c'est juste de l'autocomplétion glorifiée, rien de nouveau sous le soleil"). CodeSpeak ne se prête bien à aucun de ces deux récits, et c'est probablement son trait le plus intéressant.

Pour comprendre comment il se positionne par rapport aux outils existants, il vaut la peine de faire une comparaison directe. GitHub Copilot et ses analogues, Cursor, Junie de JetBrains, et la galaxie d'assistants intégrés aux IDE, opèrent sur le code comme artefact primaire : ils suggèrent des lignes, complètent des fonctions, génèrent parfois des blocs entiers. Ce sont des outils extraordinairement utiles, mais leur modèle conceptuel ne change pas : le développeur écrit du code, l'IA l'aide à écrire du code plus vite. Les agents IA plus récents, comme Claude Code ou les pipelines "LLM + outils" qui prolifèrent, franchissent une étape supplémentaire : ils peuvent naviguer dans les fichiers, exécuter des commandes, ouvrir des pull requests. Mais là encore, l'artefact qu'ils produisent et modifient est le code, et le code généré par des agents autonomes qui s'auto-modifient est, comme Breslav l'a souligné explicitement dans le podcast avec le Pragmatic Engineer, une source d'opacité croissante. Qui contrôle quoi, quand quelque chose s'arrête de fonctionner ?

CodeSpeak répond à cette question par un choix radical : retirer le code généré du centre de l'attention humaine et mettre les spécifications à sa place. L'LLM n'est pas un assistant qui suggère, c'est un compilateur qui exécute. La différence n'est pas seulement sémantique : elle change profondément le contrat entre développeur et machine. Le développeur ne révise pas le code généré ligne par ligne (activité qui, sur des sorties de centaines de lignes produites en quelques secondes, est en pratique souvent illusoire) ; il révise la spécification, qui est compacte, lisible, et versionnée dans Git comme n'importe quel autre document. Le code généré est, dans cette vision, un artefact intermédiaire, semblable au bytecode Java ou à l'assembly produit par un compilateur C : quelque chose qui peut en principe être inspecté, mais qui dans la pratique quotidienne n'est pas le point où se concentre la pensée.

Cela a des implications concrètes sur le flux de travail des équipes. Dans un projet CodeSpeak mature, les chefs de produit et les responsables techniques raisonnent en termes de spécifications exécutables, des documents qui décrivent ce que le système doit faire, pas comment il le fait. Les développeurs veillent à la qualité de ces spécifications et des tests associés plutôt qu'au détail de chaque fonction. Les revues de code se déplacent : au lieu de commenter les noms de variables et les choix d'implémentation, on discute de savoir si la spécification capture correctement le comportement attendu. C'est un saut conceptuel non négligeable, semblable, pour utiliser une comparaison issue du monde du design, au passage du dessin à main levée aux systèmes de design paramétrique : on ne dessine plus chaque élément, on définit les règles qui le génèrent.

Il y a cependant une question que les partisans les plus enthousiastes ont tendance à éluder : la spécification est-elle vraiment plus lisible et compréhensible que le code ? Pour des fonctions simples et bien délimitées, la réponse est presque certainement oui. Mais pour des logiques complexes, avec des dépendances subtiles entre composants et des comportements qui émergent de l'interaction de nombreuses parties, la spécification risque de devenir elle-même un document dense et difficile à maintenir. On déplace le problème plus qu'on ne le résout, et le risque est que la complexité, retirée du code, se réinstalle dans la spécification sous des formes moins structurées et donc plus difficiles à appréhender. C'est la même critique qui a été adressée aux systèmes low-code et no-code au cours de la dernière décennie : l'abstraction n'élimine pas la complexité, elle la cache, et quand elle réémerge, elle le fait dans des endroits où les outils pour la gérer sont plus rares. Image tirée de codespeak.dev

Lock-in, risques et questions ouvertes

Être honnête sur un projet en Alpha Preview signifie aussi faire face à ce qui ne fonctionne pas encore, ou qui pourrait ne jamais fonctionner comme espéré. CodeSpeak soulève une série de questions légitimes qu'il vaut la peine d'aborder sans détour.

Le premier risque est celui du lock-in technologique. Adopter CodeSpeak signifie s'en remettre à un langage propriétaire, à une chaîne d'outils spécifique, et à un fournisseur de LLM (actuellement Anthropic) pour la génération du code. Si demain le projet change de direction, que l'entreprise qui le développe ferme, ou que le modèle de tarification de l'API d'Anthropic devient insoutenable, qu'advient-il du code généré ? Techniquement, le code Python (ou tout autre langage cible) continue d'exister et est lisible, on ne perd pas le produit du travail. Mais on perd la capacité de le maintenir à travers les spécifications, ce qui signifie revenir au point de départ, avec en plus la difficulté de travailler sur un code qui n'a pas été écrit à la main et qui pourrait avoir des structures non évidentes.

Le deuxième risque concerne l'ambiguïté des spécifications. Un compilateur traditionnel est déterministe : à partir du même code source, il produit toujours la même sortie. Un LLM ne l'est pas. Deux builds successifs d'une même spécification peuvent produire un code fonctionnellement équivalent mais structurellement différent, ce qui complique le débogage, le versionnement et la compréhension de ce qui a changé et pourquoi. L'équipe de CodeSpeak a introduit les tests comme mécanisme de stabilisation (si les tests passent, le code est correct par définition), mais cela nécessite une suite de tests suffisamment complète et bien conçue. Dans les projets où les tests sont rares ou mal écrits — et ils sont bien plus nombreux qu'on ne l'admet —, le système perd l'une de ses principales bouées de sauvetage.

Le troisième risque est celui du débogage opaque. Quand le code généré ne se comporte pas comme la spécification le décrit, où cherche-t-on le problème ? Dans la spécification (ambiguë), dans le modèle (qui a mal interprété), dans la version de l'API (changée silencieusement), dans le contexte du projet (que l'LLM a lu de manière partielle) ? La chaîne causale s'allonge, et avec elle le temps nécessaire pour isoler et corriger l'erreur. L'équipe signale cela comme l'un des axes d'amélioration prioritaires dans sa roadmap, mais pour l'instant c'est une limite réelle que quiconque souhaite utiliser CodeSpeak en production doit prendre en compte.

Il y a enfin la question de la portabilité. CodeSpeak supporte aujourd'hui Python, et seulement Python. L'extension à d'autres langages est dans la roadmap, mais n'a pas encore de date. Pour la grande majorité des projets d'entreprise, qui utilisent Java, TypeScript, Go ou des stacks polyglottes, c'est une barrière à l'entrée significative.

Cela dit, il serait injuste d'utiliser ces limites pour enterrer le projet. Ce sont les limites normales d'une Alpha, pas des défauts structurels de l'idée. La question la plus intéressante n'est pas "est-ce que ça fonctionne parfaitement maintenant ?" (la réponse est évidemment non), mais "est-ce que l'idée tient la route sous pression ?". Et là, la réponse est moins évidente, et plus intéressante.

Roadmap et perspectives

La roadmap publique qui ressort des billets de blog est assez claire dans ses priorités. Le thème de la modularité, introduit avec les spec dependencies et les managed files en mars 2026, est le chantier principal : rendre les spécifications composables et réutilisables est le prérequis pour passer à des projets de taille réelle. Le codespeak takeover est en phase d'affinage : l'objectif déclaré est de garantir que la spécification extraite d'un code existant soit suffisamment complète pour pouvoir régénérer une implémentation équivalente à partir de zéro, en réussissant tous les tests originaux. Il n'y a pas encore d'annonces sur le support de langages au-delà de Python, ni sur des intégrations avec des systèmes de CI/CD.

La question stratégique de fond est de savoir si CodeSpeak peut aspirer à devenir un standard de fait pour ce que certains appellent déjà l'"AI-native programming", la conception de langages et d'outils pensés dès le départ pour un monde où une partie de l'exécution est déléguée à des modèles de langage, ou s'il restera un outil de niche, adopté par des équipes ayant une très grande discipline de test et des cas d'utilisation bien délimités. La réponse dépendra en partie de la qualité de l'exécution, en partie de l'évolution des modèles sous-jacents, et en partie de facteurs d'écosystème qu'il est aujourd'hui difficile de prévoir.

Breslav a une position claire sur le contexte plus large. Dans son dialogue avec le Pragmatic Engineer, il a affirmé que 2026 sera l'année de la renaissance des environnements de développement intégrés par rapport aux outils en ligne de commande, non par nostalgie, mais parce que les agents IA travaillent mieux au sein d'environnements structurés qui offrent un contexte riche. C'est une prédiction qui s'aligne parfaitement avec la philosophie de CodeSpeak : pas le prompt libre dans le vide, mais l'intention humaine canalisée dans des structures que la machine peut interpréter de manière fiable.

Le métier qui change

Il y a une question qui plane sur tout cela, et qui dépasse les considérations techniques : qu'advient-il du travail des développeurs dans un monde où un outil comme CodeSpeak fonctionne bien ?

La réponse superficielle, et la plus courante sur les réseaux sociaux, est que les programmeurs deviennent obsolètes. Breslav la rejette explicitement, avec une phrase qui mérite d'être citée dans son intégralité : "À l'avenir, ce seront toujours les ingénieurs qui construiront des systèmes complexes. Gardez cela à l'esprit : ce n'est pas comme si nous allions tous disparaître dans la nature." Ce n'est pas de l'optimisme de façade : c'est la même logique qui a guidé chaque saut d'abstraction dans l'histoire de l'informatique. L'assembleur n'a pas éliminé les programmeurs ; le C n'a pas éliminé les programmeurs ; les langages de haut niveau n'ont pas éliminé les programmeurs. Ils ont changé ce qu'ils font, déplaçant le centre de gravité du travail de la gestion des détails mécaniques à la modélisation conceptuelle du problème.

CodeSpeak, s'il tient ses promesses, déplace encore plus ce centre de gravité. Moins de temps à écrire du code boilerplate, plus de temps à réfléchir à ce que le système doit faire, à concevoir les tests qui en vérifient le comportement, à écrire des spécifications précises sans être rigides. C'est un travail plus proche de celui d'un architecte logiciel que de celui d'un artisan du code, et historiquement, ce type de transition a créé plus de valeur qu'il n'en a détruit, même s'il a redistribué les rôles et les compétences de manière non indolore.

Le risque réel n'est pas la disparition du programmeur : c'est la concentration des opportunités. Si maintenir un système complexe ne nécessite plus qu'un dixième des lignes de code, peut-être nécessite-t-il aussi moins de développeurs pour le maintenir. L'efficacité gagnée par les équipes les plus disciplinées pourrait se traduire par des pressions sur les effectifs, du moins à court terme. C'est le paradoxe classique de la productivité technologique : elle crée de la richesse globalement, mais la distribue de manière asymétrique dans la phase de transition.

Pour les développeurs les plus jeunes, il y a aussi une question d'apprentissage. Apprendre à programmer en écrivant du code, avec toutes les erreurs, les debuggers ouverts à trois heures du matin, la lente compréhension de la façon dont fonctionne réellement la mémoire ou le réseau, est un parcours de formation qui a sa propre logique. Un monde où le code est généré à partir de spécifications risque d'obscurcir ces couches de compréhension. Ce n'est pas un problème insoluble, les médecins apprennent aussi l'anatomie même s'ils n'opèrent plus à mains nues, mais c'est une question que le secteur devra aborder consciemment, et non laisser se résoudre d'elle-même.

Une langue pour les humains et les machines

Pour en revenir à notre point de départ, au profil de Breslav et aux leçons de Kotlin, il y a un fil rouge qui traverse toute l'histoire de CodeSpeak et qu'il vaut la peine de rendre explicite. Kotlin est né, entre autres, du constat que Java stagnait : le langage n'évoluait pas à la vitesse requise par les développeurs, et le marché était prêt pour quelque chose de mieux. CodeSpeak naît d'un constat analogue, mais inversé : les langages existants évoluent trop lentement par rapport à la vitesse à laquelle les agents IA changent la façon dont le code est produit. Il ne s'agit pas d'un langage plus ergonomique pour les humains, il s'agit du premier langage conçu explicitement pour un système où humains et LLM collaborent, chacun faisant la partie pour laquelle il est le plus doué.

Si ce pari s'avère payant, CodeSpeak pourrait représenter plus qu'un outil utile : il pourrait être le premier exemple d'une nouvelle catégorie, celle des langages "AI-native", conçus dès le départ pour un monde où la génération automatique de code n'est pas une exception mais la norme. S'il ne s'avère pas payant, pour des raisons techniques, d'adoption, ou parce que l'évolution des modèles eux-mêmes rendra l'approche obsolète, il restera de toute façon une expérience précieuse, qui aura permis de clarifier quelles sont les bonnes questions à poser.

Breslav clôt son interview par une invitation qui sonne plus comme un défi : "Il ne faut pas croire aveuglément tout ce qu'on lit sur Twitter : certaines personnes affirment des choses absurdes. Cependant, s'ils sont utilisés correctement, ces outils peuvent être très productifs et il vaut absolument la peine d'y investir." C'est le ton de quelqu'un qui a déjà traversé un cycle de hype, celui de Kotlin, et sait qu'entre l'enthousiasme initial et l'utilité durable, il y a toujours un bout de chemin difficile à parcourir. CodeSpeak est au début de ce chemin. Il mérite d'être suivi.