Un auteur de Habr « vibe-code » trois utilitaires en Rust : DirMerge, ProcessTree et Notepad

L'auteur de la série sur Habr publie une nouvelle fournée d'utilitaires écrits en Rust avec l'aide d'un LLM : DirMerge, ProcessTree et Notepad. Trois programmes, une seule question : peut-on construire avec un réseau de neurones des outils qu'une personne utilise réellement chaque jour, sans retourner à son ancien logiciel au bout d'une semaine ? L'auteur qualifie lui-même l'exercice de « schizophasie version vibe coding » : la dose d'autodérision est donnée d'emblée.

Une réserve importante : l'annonce ne mentionne ni le nom du modèle, ni le volume de code, ni le temps de développement, ni les résultats de tests. Tout ce qui suit s'appuie sur le protocole d'expérience annoncé et sur les noms des utilitaires. Les conclusions complètes de l'auteur figurent dans l'article sur Habr.

Ce qui est réellement testé

La plupart des démonstrations de vibe coding s'arrêtent au stade du « ça marche sur ma machine ». Ici, la barre est placée plus haut : l'utilitaire doit évincer un outil que l'auteur utilise déjà. C'est un critère sévère. L'utilisateur remarque les latences, la gestion approximative du clavier, les réglages perdus et les comportements étranges sur de gros volumes de données. Une application simple ne pardonne pas les petites imperfections, car on travaille dessus pendant des heures.

D'après leurs noms, on peut supposer que DirMerge fusionne des répertoires, que ProcessTree affiche les processus sous forme d'arbre et que Notepad remplace un éditeur de texte. Ce sont des tâches classiques, pour lesquelles il existe depuis longtemps des solutions éprouvées. Les nouveaux venus devront donc se mesurer à des concurrents très solides.

Pourquoi Rust, et pourquoi des outils simples

Le choix de Rust pour cette expérience n'a rien d'un hasard. Le compilateur vérifie strictement la propriété de la mémoire et les types : une partie des erreurs que les LLM commettent d'ordinaire dans les langages dynamiques est donc éliminée dès la compilation. Le résultat est un exécutable unique, sans runtime lourd. Revers de la médaille : les modèles se débrouillent moins bien avec le borrow checker et les lifetimes, et le cycle « génération, échec de compilation, correction » peut demander de nombreuses itérations.

Les utilitaires simples conviennent à ce test pour une autre raison. Leur périmètre est limité, leur comportement est clair et il est facile de les comparer à une référence. Si l'IA n'arrive pas à produire un éditeur de texte ou un affichage de l'arbre des processus, il est encore trop tôt pour compter sur elle pour des systèmes complexes.

Ce que l'on sait de l'expérience :

• langage : Rust ;
• méthode : vibe coding avec un LLM ;
• nombre d'utilitaires dans cette partie : trois (DirMerge, ProcessTree, Notepad) ;
• critère : remplacer les outils que l'auteur utilise en pratique ;
• principal risque cité par l'auteur : des problèmes insolubles, qui obligeraient à revenir à l'ancien logiciel ;
• le modèle, le volume de code et les métriques de performance ne sont pas divulgués dans l'annonce.

Comment tirer parti de cette expérience

Si vous voulez reproduire l'expérience, commencez par un outil facile à vérifier. Choisissez une tâche dotée d'une référence nette, par exemple un utilitaire de comparaison de dossiers, et formulez vos critères d'acceptation à l'avance : combien de fichiers il doit traiter, quels raccourcis clavier sont nécessaires, ce qui compte comme une régression. Gardez l'ancien outil à portée de main pendant au moins deux semaines.

Observez précisément où le modèle déraille. Les points sensibles habituels : la gestion des chemins et des encodages selon les OS, la fiabilité sur de gros répertoires, le presse-papiers et le focus des fenêtres. Ce sont ces détails qui séparent un prototype d'un programme réellement utilisable. Cette série mérite d'être lue pour ces enseignements, et non pour les utilitaires eux-mêmes.