Un adepte du vibe coding crée en 4 jours un bot pour Yandex Lavka, avec 498 tests et sans droit de payer

Chaque semaine, la même conversation revient à la maison : « Qu’est-ce qu’on mange ? » — « Qu’est-ce qu’il reste ? » — « Un demi-paquet de riz et du poulet qui ne va plus tenir longtemps. » L’auteur d’un article sur Habr a décidé de confier ce casse-tête à un bot. Il n’est pas développeur professionnel, utilise Python pour ses besoins personnels et laisse des agents IA écrire le code à sa place. Résultat après 4 jours et 143 commits : un bot Telegram doté d’une Mini App, qui connaît le contenu du réfrigérateur, prépare des menus et remplit un panier chez Yandex Lavka.

Le bot ne peut pas payer : le code ne contient tout simplement aucun outil permettant de passer commande ou de régler un achat. C’est la première règle du projet. Le modèle peut se tromper de produit, de quantité ou de prix ; autant que ces erreurs restent dans un panier qu’une personne vérifiera avant de payer.

Le modèle propose, le code vérifie

Ce principe mérite d’être repris dans tout projet utilisant un LLM. Le modèle imagine les plats et choisit un produit parmi les références trouvées. Tout ce qui peut être calculé l’est par le code : exactement N jours, des calories à ±15% de l’objectif, un montant ne dépassant pas le budget majoré de 15%, le nombre de paquets et la disponibilité en stock. Toute violation est renvoyée au modèle pour correction, avec une indication précise du problème.

Prenons les oignons. Le menu demandait 950 g d’oignons et 900 g de bœuf, mais le code arrondissait systématiquement le nombre de paquets à l’entier supérieur : trois paquets de 400 g se retrouvaient dans le panier. La correction a porté sur deux points : une portion de 30–40 g par personne a été ajoutée au prompt, et une tolérance a été introduite dans le code.

Si le poids obtenu avec des paquets entiers reste inférieur au besoin de 15% au maximum, aucun paquet supplémentaire n’est ajouté. Autre cas : le réfrigérateur contenait du « fromage frais », mais le menu indiquait « fromage frais à 5% ». Le bot n’a pas reconnu le produit et en a acheté davantage.

Une correspondance fondée sur les mots, plutôt qu’une égalité exacte, a résolu le problème.

La méthode compte aussi : un cahier des charges élaboré en posant les questions une par une, un plan découpé en petites tâches, du TDD et une revue par un autre agent utilisant un autre modèle. La première revue a révélé 8 problèmes sérieux. Par exemple, l’enregistrement du menu commençait par écraser le fichier, puis pouvait échouer lors du rendu et corrompre les données. Un fichier STATE.md, doté d’une section « Pièges », sert de mémoire partagée entre les agents.

Ce que les 498 tests n’ont pas détecté

Tous les tests utilisaient des mocks. Or un mock n’est que la représentation que l’agent se fait de l’API. Le premier essai en conditions réelles a révélé neuf défauts.

Le principal : l’adresse détermine l’entrepôt de préparation. Le panier semblait parfait, mais, dans l’application, la moitié des références étaient indiquées comme « Épuisées », alors que l’API les annonçait « en stock ». L’agent avait pris la première adresse des favoris, tandis qu’une autre était sélectionnée dans l’application. La solution : modifier ensemble l’adresse et l’identifiant du lieu, vérifier la disponibilité sur la fiche produit, attendre 2 secondes après l’ajout puis relire le panier. Le prix d’un produit témoin, comme le riz ou le sarrasin, doit aussi correspondre à celui de l’application au rouble près.

Les autres pièges sont tout aussi familiers. Chromium ajoute à la valeur du cookie 32 octets correspondant au hachage du domaine ; sans les retirer, httpx plante. L’agent lançait la version de la veille du serveur depuis site-packages au lieu de la nouvelle version : il disposait de 14 outils au lieu de 15.

Par défaut, le modèle « réfléchissait » : environ 95% des tokens partaient dans le raisonnement et la génération du menu dépassait 120 secondes. Le raisonnement a donc été désactivé pour les tâches du type « renvoie du JSON ». Un menu proposait le même déjeuner cinq jours de suite tout en respectant formellement le budget ; le code vérifie désormais les répétitions et la part occupée par une même source de protéines.

Limites et enseignements

Le bot utilise l’API web non officielle de Lavka avec des cookies de session. Il peut donc cesser de fonctionner à tout moment, et Yandex pourrait voir cette utilisation d’un mauvais œil. L’auteur ne publie pas le code : les cookies donnent accès à l’intégralité du compte, ce qui complique une distribution sécurisée. Il utilise lui-même un compte distinct, sans carte disposant de fonds, et ne transmet au modèle que les noms des produits, les formats de conditionnement et les prix.

Les enseignements pratiques pour les développeurs et les équipes produit sont les suivants. Premièrement, confiez tous les calculs au code plutôt qu’au LLM, et renvoyez au modèle des indications précises sur les problèmes. Deuxièmement, pour faire respecter une interdiction comme « ne pas dépenser d’argent », l’absence de l’outil nécessaire est plus fiable qu’une consigne dans le prompt. Troisièmement, lancez un essai en conditions réelles le plus tôt possible, car les mocks masquent les bugs les plus coûteux. Quatrièmement, donnez aux agents un fichier partagé recensant les pièges : il fera gagner plus de temps qu’un changement de modèle.