Les problèmes engendrés par le codage vibratoire, que nous avons abordés dans des articles précédents, sont suffisamment graves pour devenir la cause de la prochaine grande catastrophe informatique. Il est temps de passer à la programmation assistée par l'IA, qui offre une approche plus professionnelle (et moins risquée). Elle est idéale pour les programmes destinés à des environnements exigeant sécurité et stabilité.
Dans cet article, nous commencerons par aborder les problèmes les plus courants liés au codage vibratoire et expliquerons pourquoi, malgré le bruit médiatique autour de certains promoteurs, il ne constitue pas la nouvelle révolution industrielle. Dans les sections suivantes, nous développerons la procédure permettant de passer du codage par intuition à la programmation assistée par IA sous Linux.
Les problèmes du codage vibratoire
Prenons un exemple : deux personnes se rendent dans un restaurant chic. L’une n’y connaît rien en cuisine, l’autre est un chef expert. La première sait seulement ce qu’elle veut manger et, tout au plus, jugera la qualité de son plat au prix ou à son palais non exercé. La seconde sera capable de distinguer si des ingrédients frais ont été utilisés, si les assaisonnements sont dosés correctement et si le prix est justifié.
Ce n'est pas un hasard si nous prenons l'exemple d'un restaurant. Andrej Karpathy, expert en intelligence artificielle, est l'un des cofondateurs d'OpenAI et directeur de l'intelligence artificielle chez Tesla. Souhaitant résoudre le problème de l'indécision quant au choix des plats, il a créé une application utilisant le codage vibratoire qui affiche une photo de chaque plat. Voici comment il décrit son expérience :
« Créer MenuGen avec le codage vibe était amusant en tant que démo locale, mais assez difficile en tant que véritable application. Construire une application moderne, c'est comme assembler des meubles IKEA du futur : beaucoup de services, d'API, de configurations, de limites et de prix. » Les titulaires d'un LLM possèdent des connaissances obsolètes, commettent des erreurs subtiles et sont sujets à des hallucinations. Le plus drôle, c'est que je n'ai quasiment pas codé, mais plutôt configuré des services dans le navigateur. Tout ça n'est même pas accessible aux titulaires d'un LLM. Comment est-ce qu'on est censés tout automatiser d'ici 2027 comme ça ?
Examinons plus en détail ce qui est arrivé à Andrej, qui, soit dit en passant, Il n'est pas développeur web, ce qui l'a probablement conduit à compliquer les choses inutilement.
« J'ai utilisé Cursor + Claude 3.7, je lui ai donné la description de l'application, et il a écrit tous les composants frontend en React très rapidement, créant un magnifique site web avec des polices multicolores douces, de petites animations CSS, un design réactif et tout ça, à l'exception des fonctionnalités backend proprement dites. »
Le frontend et le backend sont les deux faces d'une même pièce dans la conception d'applications. L'interface utilisateur (front-end) est la partie avec laquelle les utilisateurs interagissent, tandis que le serveur (back-end) traite et stocke les informations. L'interface utilisateur fonctionne en local, tandis que le serveur est généralement développé sur un serveur externe.
Claude est, du moins parmi les adeptes du codage par vibrations, le langage modèle incontournable du moment. Les raisons de cette situation sont davantage idéologiques que techniques. Anthropic, la société qui développe le produit, s'est opposée au Pentagone concernant l'utilisation non supervisée de ses modèles par l'armée.
Cursor est un éditeur de code dans lequel le modèle d'intelligence artificielle intégré fait office d'assistant de programmation. Nous parlerons plus tard de la manière d'installer Cursor sous Linux.
React est une bibliothèque permettant de créer des interfaces graphiques dynamiques. Je ne connais pas l'application, je ne peux donc pas juger de la pertinence de l'utilisation de React, mais d'après mon expérience avec Vibe coding, les modèles ont tendance à utiliser des bibliothèques pour des tâches qui pourraient être parfaitement réalisées avec du HTML, du CSS et du JavaScript purs.
C’est au niveau du développement backend que les choses ont commencé à se compliquer pour Karpathy. Leur application commence par la prise d'une photo du menu, puis utilise la reconnaissance optique de caractères pour rechercher des informations sur chaque plat. Voici leur description du processus :
« C’est là que les problèmes ont commencé. J’avais besoin d’utiliser les API d’OpenAI pour effectuer une reconnaissance optique de caractères (OCR) sur les éléments du menu à partir de l’image. Il me fallait obtenir les clés API, et naviguer dans des menus assez complexes concernant les « projets » et les autorisations détaillées. » Claude était stupéfait par les API obsolètes, les noms de modèles et les conventions d'entrée/sortie récemment modifiées.C'était déroutant, mais j'ai fini par trouver la solution après avoir copié-collé la documentation à plusieurs reprises. Une fois les appels API fonctionnels, je me suis immédiatement heurté à des limitations de débit assez strictes, qui ne m'autorisaient qu'à effectuer quelques requêtes toutes les 10 minutes.
Voici un exemple classique de la tendance des maquettes à utiliser un canon pour tuer des mouches. La reconnaissance de l'image du menu aurait pu être effectuée avec une bibliothèque locale comme Tesseract.js.
Tesseract.js est basé sur l'outil du même nom de Google et prend en charge plus de 100 langages. Il s'utilise directement depuis le navigateur et, surtout, ne consomme pas de jetons, ne nécessite pas de clés API et est sans limitation.
Malheureusement, il n'existe aucune solution aux hallucinations provoquées par les API obsolètes et l'utilisation d'une documentation périmée. Sauf pour l'apprentissage de la programmation et le fait de ne pas utiliser d'outils automatisés.
Il a rencontré des problèmes similaires avec la deuxième partie de l'application : la conversion de la description de chaque plat en images.
"Je me suis inscrit, j'ai obtenu une clé API Replicate et j'ai rencontré des problèmes similaires. Les requêtes ne fonctionnaient pas car les connaissances sur LLM étaient obsolètes, et cette fois-ci, même la documentation officielle était quelque peu dépassée en raison de récentes modifications de l'API. qui ne renvoie plus de JSON direct mais un objet en flux continu que ni Claude ni moi ne comprenions vraiment. Je me suis ensuite heurté à nouveau à des limites d'utilisation, ce qui a compliqué le débogage. On m'a expliqué plus tard qu'il s'agissait de mesures antifraude courantes, mais qu'elles rendaient également plus difficile la création de nouveaux comptes légitimes. On m'a indiqué que Replicate était en train de migrer vers un modèle de crédit prépayé, ce qui pourrait s'avérer utile.
Andrej aurait pu résoudre ce problème sans avoir recours à des générateurs d'images. Plusieurs outils permettent de rechercher de véritables images de plats (évitant ainsi les illusions potentielles de l'IA). Parmi eux, deux API de bases de données de recettes : TheMealDB et Spoonacular Food API.
Les problèmes ne s'arrêtaient pas là pour notre ami le codeur d'ambiance. Lors du chargement de l'application sur Vercel (une plateforme permettant de déployer et d'héberger des applications à partir d'un dépôt GitHub), des erreurs sont apparues qui ne se produisaient pas en local.Il nous a fallu une heure pour nous rendre compte que les clés API n'avaient pas été chargées sur le serveur. Un programmeur expérimenté l'aurait su et aurait ainsi économisé les frais liés aux jetons.
L'idée de l'auteur est de rendre l'application payante (je me demande bien qui paiera pour quelque chose qu'il peut obtenir gratuitement en demandant à Gemini ou Siri). Pour cela, il a besoin d'une authentification. Sur la suggestion de Claude, Karpathy s'est tourné vers une autre plateforme cloud appelée Clerk. Clerk gère tout ce qui est nécessaire à l'inscription et à l'accès. Je n'ai aucune objection à ce choix.
Le problème est que Claude a écrit le code pour une version obsolète de l'API Clerk et a oublié de lui dire que s'il voulait l'utiliser en production, il avait besoin de son propre domaine et Pas la version gratuite fournie par Vercel. Il a dû l'acheter et la configurer.
La mise en place de la plateforme de paiement a également posé problème. Lorsqu'il a finalement réussi à la déployer en production, il a constaté que :
« Tout le traitement était en temps réel, sans aucune persistance. Si le délai était trop long, le traitement échouait. Si l'on actualisait la page, toutes les données étaient perdues. La solution idéale aurait été une base de données et un système de file d'attente. Mais cela impliquait davantage de services (par exemple, Supabase, Upstash), et donc une complexité accrue. Trop complexe. J'ai préféré reporter cela à plus tard. »
La solution consiste plutôt à apprendre à programmer ou à faire appel à un professionnel. Dans le prochain article, nous aborderons les étapes à suivre pour y parvenir.
