QUOI ? TOI AUSSI TU VIBECODES ???

Oui.

Pourquoi ?

Car clairement, c'est beaucoup plus rapide, l'IA fait moins d'erreurs que moi, et peut s'inspirer de papiers de recherche que je n'ai pas lu. Elle lit la doc plus vite et écrit du code plus vite.

Expérience ?

Mon premier test était sur un solveur de rubix cube en python, et il était incapable de faire une fonction de pretty print pour afficher un rubix cube dans le terminal, ou faire une table de transposition. C'était le début de chatgpt et les chaines de pensées ne fonctionnaient pas bien. Naïf que j'étais, j'ai fermé les yeux sur cette technologie pendant un moment.

Tout a réellement commencé par déléguer des tâches qui m'ennuient profondément et pour lesquelles je suis mauvais : les squelettes et CSS de sites webs. Conscient des limitations des llms pour coder, j'en restais là mais en imaginant des méthodes pour à l'avenir pouvoir vibecoder un projet entier : typage fort, programmation dirigée par les tests unitaires, etc...

Premiers tests avec open code et des modèles gratuits, ça marchottait mais ça pouvait aussi coincer : j'avais tenté de lui faire coder une simulation de la théorie de l'évolution dans l'eau et ça partait vite en n'importe quoi.

Tests suivants avec codex (openai, chatgpt, probablement 4.5) à partir de mars 2026. à partir de là, j'ai codé les choses suivantes :

développement de sites complexes en ocaml avec Dream (site d'administration système qui lance des tâches, site de rubix cube, site de QCM de philosophie, réseau social, carte du monde pour afficher de l'opendata, un lecteur de BD, un site pour planifier ses voyages en camping/camping car/projets photos, un lecteur markdown, un lecteur de RSS avec un filtre bayésien pour savoir si c'est intéressant ou non), un site de video-teck qui propose aussi d'enregistrer des bookmarks et extraire des clips.
une application android faite en ocaml (avec une lib pour faire du caml pour android facilement)
un moniteur de projets qui envoie les informations de compilation/tests sur home assistant.
un logiciel qui cherche si on a des vidéos en double, ou qui aide à les classer dans des dossiers.
un plugin gimp
un plugin emacs
des scripts pythons et services systemd pour avoir des services d'AI locale en place.

Le seul projet sur lequel j'ai échoué, c'est à nouveau celui de simulation de la théorie de l'évolution.

Mon lecteur de markdowns

J'avais une idée quand j'étais ado : j'avais envie d'avoir un blog qui permette d'éditer plein de types de contenus, et les intégrer dans un article de blog. Le format markdown moderne permet d'intégrer des images et du mermaid et ça m'a bien inspiré : j'ai fait un lecteur de markdown, y ai intégré des images, un lecteur vidéo, du mermaid, du code coloré, mais aussi : des shémats électroniques, des partitions de musique, des parties et positions d'échecs avec des variantes (crazyhouse, bughouse, etc...) des diagrames de venn, des histogrames et courbes, je voulais aussi que les liens puissent avoir une preview : la carte qui s'affiche dans les partages sur les réseaux sociaux s'affiche quand on passe la souris, etc...

Et ce qui est rigolo c'est que je n'ai utilisé aucune librairie pour ça : pour la coloration j'ai demandé à codex de recoder une lib spécifique, pour les échecs idem il a recodé un générateur de coups y compris pour les variantes avec des tests unitaires de PERFT pour vérifier qu'on a bien les bons nombres de coups. Pour mermaid, j'avais envie de pouvoir faire des flèches d'un subgraph à un autre et c'était une limitation de mermaid donc je lui ai demandé de recoder de zero un moteur.

Et pour ça, j'ai du être intelligent pour quelle partie ? Un peu pour l'organisation du projet, et un petit peu pour l'algorithme d'allocation des pistes pour l'électronique.

Ah et j'ai aussi bricolé quelque chose pour avoir des éditeurs : non seulement on peut afficher ces extensions de markdown mais on a aussi de quoi éditer ces différentes parties, et là encore je n'ai pratiquement fait que lui dire ce que je voulais comme rendu. L'éditeur a aussi un correcteur orthographique (projet externe pas fait avec l'AI) intégré au moteur.

Quand j'ai du gtk ?

Et bien ça reste du caml, mais il génère des stubs C et ça marche très bien. Il manque une librairie ? Pas grave, elle existe en C, et générer ces stubs c'est une tâche très mécanique sur laquelle l'AI n'échoue pas.

Pourquoi ocaml ?

Quand je testais opencode pour lui faire produire du javascript, j'avais souvent des erreurs terribles : syntaxe, unbound variable, etc... Ces erreurs me demandaient des tests manuels. Avec ocaml, j'ai la certitude que ces erreurs n'arrivent pas. De plus, un code ocaml prend significativement moins de tokens que la plupart des autres langages, vu qu'on peut exprimer de façon très dense beaucoup de choses. C'est aussi un langage avec des interfaces .mli pour masquer les fonctions internes à un module, et extraire seulement la signature des fonctions publiques. Ces signatures peuvent de plus exprimer beaucoup de contraintes et de sens.

Ainsi, on peut :

Détecter automatiquement les erreurs de typage/bindings/syntaxe
Avoir un contexte de travail réduit quand on fait une tâche
Ne pas relire tout un gros projet mais se contenter de relire des .mli, et le .ml de ce qu'on veut modifier
En cas de refactoring dans un gros projet, avoir le compilateur qui indique très très facilement les erreurs
peu de tokens ? C'est mon pari. Comme le code est dense, non seulement on a un contexte réduit, mais aussi une facture faible. Malheureusement c'est très théorique. En pratique, les llms sont assez peu entrainées sur de l'ocaml donc c'est pas aussi automatique que ça, surtout quand le code est complexe.

Alors bien sur ocaml n'a pas les librairies standard les plus agréables : il manque beaucoup de choses, et parfois on a plusieurs librairies qui font la même chose mais aucune librairie n'est officielle. Donc on a des choix à faire. MAIS l'IA sait bien faire ces choix, et elle sait aussi réécrire les librairies manquantes sans trop de problème.

Limites ?

Les limites sont nombreuses :

la quantité de tokens bouffées peut être assez grosse, cependant là je fais tout avec un abonnement autour des 20€ mensuel, et ça me suffit.
parfois l'IA peut faire semblant d'avoir terminé son travail alors qu'elle n'en a fait qu'un bout, et ça peut faire semblant de fonctionner malgré tout.
l'organisation du projet, et parfois les idées de structures de données ou algorithmes à utiliser peuvent encore demander une expertise, cependant on a plus besoin de coder le projet, seulement d'expliquer à l'IA comment le projet doit fonctionner. Et surprise : en général, en proposant une idée, l'IA nous explique comment faire encore mieux. Sur ce point, le couple AI+humain est meilleur qu'AI seule ou qu'humain seul. ça demande par contre de garder une maitrise sur ce que l'AI sort. Et ça c'est pas toujours évident.
Si on colle une GADT non pas comme preuve d'un programme mais comme vérrou sur une base de donnée, alors l'AI peut vouloir à un moment effectuer directement sa requete sans vérifier le vérou. Là je donne un exemple précis, mais il faut bien comprendre le cas général : si on demande à l'AI d'effectuer une tâche, il est parfaitement possible qu'elle oublie quelques règles de sécurité, voir qu'elle les contourne pour effectuer malgré tout sa tâche.

Le futur :

On ne peut plus relire tout le code que l'AI produit. Ce qu'il faut, c'est avoir une sorte d'isolation et des garanties de contraintes. Ocaml n'est pas parfait pour ça mais est probablement parmi les meilleurs langages : si j'ai un dossier libData et que c'est le seul qui dépend du SQL, que j'ai un type privé pour l'authentification, alors je suis sur de n'avoir que l'authentification et le module de base de données à relire pour vérifier les contraintes de sécurité.

j'ai fait un test avec des GADT, quand c'est simple : vérifier ce genre de choses sur l'authentification et les permissions, c'est ok et ça ne bouffe pas trop de tokens. Quand il s'agit de prouver des propriétés d'un algorithme c'est beaucoup plus couteux en tokens. Probablement pour les raisons évoquées plus haut.

Aujourd'hui, Claude s'amuse à écrire des preuves pour des librairies open source, je l'ai fait pour tester, avec des GADT sur des algorithmes de votes et de mariages stables ou affectations (APB/parcoursup) et ça fonctionne MAIS ça m'a bouffé des quantités astronomiques de tokens. Actuellement c'est pas parfait pour faire ça.

Le futur bis :

Ce qu'on veut, c'est en gros envoyer un cahier des charges, récupérer :

un projet qui fonctionne
une preuve qu'il fonctionne et qu'il est sécurisé

La question principale est vraiment la preuve. Actuellement on se contente de tests unitaires, de prompts : "vérifie que tout va bien (insiste sur ...) et fait moi un rapport", ainsi que de tests réalisés à la main ou avec des outils de scénarios.

Mais voilà, preuve a deux sens :

preuve mathématique : conclusion qui découle logiquement des prémisses
élément matériel qui donne des raisons de penser que

Et en général ce qu'on produit s'inscrit dans la seconde case, et c'est assez faible : si c'était fort alors on aurait aucun bug et aucune faille dans nos programmes.

Pour arriver aux preuves mathématiques, on doit nécessairement faire en sorte que l'AI produise cette preuve et qu'elle soit vérifiée par un programme déterministe puis que la signature de la preuve soit relue par un humain (la propriété qu'on veut prouver) Et ça, avec ocaml et les GADTs on peut -un peu- le faire. Si les modèles étaient entrainées sur plus de données de type preuve, ou plus de caml en général, on peut parier sur une nette augmentation de ses performances pour ça.

Beaucoup de langages ont été conçus pour avoir des développeurs à pas cher. Clairement, aujourd'hui l'AI développe mieux que tous les développeurs, et peut probablement mieux exploiter des concepts mathématiques complexes qui permettent d'avoir de fortes garanties statiques à la compilation. Python, java, rust, C, C++, javascript, etc... ne sont pas l'avenir. Ocaml n'est même que probablement transitoire. à mon avis, ce dont on a besoin c'est Coq ou ocaml ou autre, gros langage strict.

Le but c'est d'avoir à la fin, le plus de garanties statiques. Aujourd'hui, caml pur, demain GADT ou coq, dans quelques années, un nouveau langage spécialement conçu pour. C'est ça qui offre les meilleures preuves à ma conaissance.