Discussion :

[Mathis Lucas]

Un programmeur utilise l'IA Claude Code pour créer un pilote Wi‑Fi natif FreeBSD pour la puce Broadcom BCM4350
l'expérience illustre à la fois les possibilités et les limites de l’IA dans le génie logiciel

Un développeur a entrepris d'utiliser l'IA pour créer un pilote Wi‑Fi natif FreeBSD pour une puce Broadcom BCM4350. Claude Code a échoué lorsqu'il a travaillé sans une planification. Dans un second temps, l'IA a généré une spécification complète du pilote, puis le code lui-même, en testant et ajustant les versions successives jusqu’à obtenir un module noyau fonctionnel capable de gérer la recherche de réseaux, la connexion aux bandes 2,4 GHz et 5 GHz, ainsi que l’authentification WPA/WPA2. L'ensemble du processus a été automatisé, sans que le développeur ait écrit manuellement le code final, illustrant à la fois les possibilités et les limites de l’IA dans le génie logiciel.

Les fabricants de modèles d'IA soutiennent que la technologie va révolutionner l'ingénierie logicielle en automatisant la génération de code, les tests et la détection de bogues, ce qui accélèrera le développement et améliorera la qualité. L'IA vise à transformer le cycle de vie des logiciels et augmenter la productivité des développeurs. Cependant, les tests menés en conditions réelles ont donné des résultats contrastés, avec des coûts parfois très élevés.

Le développeur Varankin Vladimir possède un vieux MacBook Pro 2016 qui prenait la poussière. Il a décidé de le recycler pour jouer avec FreeBSD. Problème : la puce Wi-Fi Broadcom BCM4350 de l'appareil n'est pas supportée nativement par FreeBSD. La solution habituelle consiste à faire tourner une petite VM Linux (wifibox) pour gérer le matériel via le pilote Linux brcmfmac. Il voit là une nouvelle occasion de créer un vrai pilote natif pour FreeBSD.

Acte 1 : l'approche naïve avec Claude Code

L'idée initiale est simple : demander à Claude Code de porter le code Linux de brcmfmac vers FreeBSD, en s'appuyant sur LinuxKPI, la couche de compatibilité de FreeBSD. Le module a bien compilé, mais une fois testé sur le vrai matériel, les paniques noyau s'enchaînaient. L'agent accumulait des rustines et des wrappers #ifdef, le diff grossissait démesurément, et le pilote ne fonctionnait toujours pas. L'approche brute-force avait atteint ses limites.

Acte 2 : écrire une spécification d'abord

Inspiré par une vidéo du développeur de logiciels open source Armin Ronacher sur l'agent Pi, Varankin Vladimir change radicalement de méthode. Plutôt que de coder directement, il demande à l'IA de produire une spécification détaillée du fonctionnement interne du pilote brcmfmac, focalisée sur le chip BCM4350. Le résultat est un "livre" de 11 chapitres couvrant les structures de données, le protocole, le firmware, la gestion des événements, etc.

Pour s'assurer de la fiabilité, il fait relire la spécification par un second agent (Codex), puis valider les corrections par un troisième (Opus), en posant systématiquement le code source comme référence de vérité. Ce processus itératif de relecture croisée entre modèles lui permet d'obtenir une base documentaire solide.

Acte 3 : construire le pilote proprement

Armé de sa spécification, il lance un nouveau projet. Avant tout codage, il demande à l'agent de lister les décisions importantes à prendre et de tout documenter dans un fichier AGENTS.md pour que les sessions futures restent cohérentes. Le travail devient alors une routine productive : l'agent dispose d'un accès SSH à la machine de build et à la VM de test, avance méthodiquement selon ses propres jalons, et documente chaque progression.

Quand un crash survient, Varankin Vladimir ouvre une session distincte pour analyser et enregistrer le problème avant de le corriger. Enfin, un module noyau FreeBSD fonctionnel pour BCM4350 voit le jour, supportant le scan réseau, la connectivité 2,4 GHz/5 GHz et l'authentification WPA/WPA2.

Le rapport indique que le développeur n'a lui-même écrit aucune ligne de code. Le pilote fonctionne pour certaines tâches, mais il comporte encore des problèmes connus et n’est recommandé qu’à des fins d’étude et de test, pas pour un usage en production. L'expérience illustre aussi la valeur et les limites de l’IA dans des tâches complexes de développement logiciel. Le code source du pilote est publié sur GitHub (dépôt : narqo/freebsd-brcmfmac).

L'expérience mitigée menée par Anthropic avec Claude

Anthropic a annoncé qu'une équipe de 16 agents Claude Opus 4.6 ont écrit, en deux semaines et sans accès à Internet, un compilateur C en Rust de 100 000 lignes. Le compilateur est capable de compiler Linux et même le jeu Doom, Anthropic estimant qu'il s'agit d'une avancée. Mais lorsque l'on examine de plus près les performances réelles, l'utilité et la qualité du code, le discours passe de « percée révolutionnaire » à « expérience très coûteuse ».

Les tests suggèrent que les modèles excellent pour les parties « faciles » de la conception des compilateurs, mais échouent dans la logique algorithmique complexe requise pour l'optimisation. Les compilateurs se composent de deux parties : le frontend (analyse du texte) et le backend (optimisation de la logique). L'IA excelle dans l'analyse, qui est une tâche linguistique. Claude Opus semble bien maîtriser la traduction de la syntaxe C en structures Rust.

Cela prouve que si l'IA peut reproduire les éléments standard d'un système complexe, elle ne peut pas encore « raisonner » pour résoudre des problèmes d'ingénierie de haute performance. Les critiques craignent que les entreprises trop enthousiastes remplacent précipitamment les programmeurs humains par l'IA. Les conséquences sur le long terme pourraient être désastreuses, car l'IA n'est pas encore douée pour la logique et les mathématiques.

Analyse du coût de développement de 20 000 dollars

Dépenser 20 000 dollars pour reproduire un outil qui existe déjà gratuitement (GCC/Clang), et le reproduire de manière médiocre, soulève des questions. Pour le même montant, une entreprise pourrait embaucher un développeur junior pendant quelques mois. Ce développeur junior apprendrait, s'améliorerait et contribuerait à terme à la santé à long terme du code source. Les crédits consommés par l'IA lors de l'exécution sont un coût irrécupérable.

Le modèle n'apprend pas du projet d'une manière qui profite directement au projet suivant, et il ne reste pas pour corriger les bogues. Cependant, considéré comme de la recherche et du développement, le coût est justifiable. Selon certains analystes, l'expérience d'Anthropic prouve qu'il est possible de gérer la fenêtre contextuelle et la coordination de 16 agents parallèles. La valeur n'était pas le compilateur, mais les données du flux de travail.

Rapport Octoverse : l'IA amplifie les mauvais patterns

Le dernier rapport GitHub Octoverse comporte quelques observations sur l'utilisation de l'IA générative dans le domaine de l'ingénierie logicielle. L'une des recommandations les plus importantes du rapport GitHub Octoverse mérite d'être mise en avant : « standardisez avant de scaler. Documentez vos patterns. Publiez des dépôts de templates. Rendez vos décisions architecturales explicites. Les outils IA reproduiront les structures qu'ils observent ».

Ce conseil contient une mise en garde implicite de première importance. Si les grands modèles de langage (LLM) apprennent à reproduire les patterns existants dans votre base de code, ils vont également reproduire les mauvais patterns. Ces derniers comprennent notamment : la dette technique, les raccourcis, les conventions bancales héritées d'une époque révolue, etc. L'IA est un miroir architectural d'une fidélité redoutable. Elle amplifie l'existant.

Une base de code saine donnera des suggestions cohérentes et solides. Une base de code chaotique produira du chaos généré à vitesse industrielle. Pour les équipes d'ingénierie, l'enjeu n'est plus seulement de maîtriser les outils d'IA, mais d'investir en amont dans la qualité structurelle de leur environnement.

Des entreprises paient sévèrement les errements des agents de codage

Le PDG de Replit, Amjad Masad, fait partie de ceux qui pensent que les générateurs de code permettront de démocratiser le développement de logiciels, ce qui rendra à l'avenir le recours aux codeurs professionnels moins indispensables. Mais des incidents démontrent que la vigilance humaine reste importante dans la filière. L'année dernière, le PDG de Replit s'est excusé après l’effacement par son agent d'IA de la base de code d’une entreprise.

Un investisseur en capital-risque voulait voir jusqu'où l'IA pouvait l'amener dans la création d'une application. Elle l'a mené assez loin pour détruire une base de données de production en direct. L'incident est survenu au cours d'une expérience de vibe coding de 12 jours menée par Jason Lemkin, investisseur dans des startups spécialisées dans les logiciels. Comme cela a été rapporté, au neuvième jour du défi de vibe coding, les choses ont mal tourné.

Malgré l'instruction de geler toutes les modifications de code, l'agent d'IA de Replit a agi de manière incontrôlée. « Il a supprimé notre base de données de production sans autorisation », a écrit Jason Lemkin dans un billet sur X (ew-Twitter). « Pire encore, il l'a caché et a menti à ce sujet », a-t-il ajouté.

L'outil Gemini CLI de Google a également été impliqué dans un incident similaire. L'incident Gemini CLI s'est produit lorsqu'un chef de produit qui testait l'outil en ligne de commande de Google a vu le modèle d'IA exécuter des opérations sur des fichiers qui ont détruit des données alors qu'il tentait de réorganiser des dossiers. La destruction s'est produite à la suite d'une série de commandes de déplacement ciblant un répertoire qui n'a jamais existé.

Conclusions et mise en garde

Le projet du développeur Varankin Vladimir démontre que le fait de demander à une IA de porter du code directement est rarement suffisant pour des tâches complexes. Ce qui a fait la différence, c'est de faire planifier, documenter et itérer l'agent plutôt que de simplement lui demander de « coder ». La spécification écrite en amont, la traçabilité des décisions et la mémoire inter-sessions ont transformé un effort chaotique en progression structurée.

Le pilote reste expérimental, mais l'expérience valide une méthode de travail avec l'IA bien plus efficace que l'approche naïve. Varankin Vladimir affirme que le codage avec l'IA n'a pas changé les principes fondamentaux de l'ingénierie logicielle. Du moins pas encore. « Les agents ont accéléré la partie production de code, tout comme d'autres outils ont accéléré le processus de collaboration, de recherche de bogues, etc. », a conclu le développeur.

Dans le cas d'Antrhopic, le code généré est moins efficace que GCC et certains projets ne compilent tout simplement pas. La vraie inquiétude est que des entreprises, aveuglées par le battage médiatique, licencient des développeurs pour les remplacer par une IA inefficace. L'IA reste un outil utile, mais elle exige une expertise humaine pour être efficace. Dans le cas contraire, ses lacunes pourraient augmenter la charge de travail plutôt que de la réduire.

Source : billet de blogue

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous de l'expérience du développeur de logiciels Varankin Vladimir ?
Ses conclusions portant sur l'utilisation de l'IA dans le génie logiciel sont-elles pertinentes ?
L'IA semble mieux accomplir ses tâches lorsqu'elle travaille en équipe avec l'humain. Qu'en pensez-vous ?
Quelles conclusions ces expérimentations permettent-elles de tirer quant à l’impact potentiel de l’IA sur la main-d’œuvre à l’avenir ?

Voir aussi

Des tests révèlent les lacunes profondes du compilateur C créé par l'IA Claude d'Anthropic pour 20 000 dollars : l'outil est nettement moins efficace que GCC et peine à réaliser des optimisations de base

Une faille dans le nouvel agent de codage Gemini CLI de Google aurait pu permettre à des pirates informatiques d'exfiltrer des données ou d'exécuter du code malveillant arbitraire sur la machine ciblée

L'IA peut-elle remplacer des développeurs professionnels ? Gemini CLI de Google et Replit ont commis des erreurs qui ont entraîné la suppression des données, inventant des répertoires, falsifiant des tests

[Mister Nono]

Cet exemple, montre que l'IA ne sait qu'écrire du code et encore mal. D'ailleurs la plus grande valeur ajoutée d'un logiciel n'est pas le code mais toute l'analyse et les méthodes algorithmiques qui l'accompagnent.

Il faut une véritable analyse faite par un être humain qui permettra ensuite à l'IA d'avancement vers l'objectif final.

L'IA est et reste donc une machine virtuelle comme toute autre machine appelée vulgairement "smart system". Pour que cela fonctionne, il lui faut des instructions.
Dit d'une autre manière il faut qu'un être humain lui crée un mode d'emploi appelé ALGORITHME. CQFD

Donc l'IA n'est qu'un assistant...

[kain_tn]

Sans compter les problèmes de licences sur le code généré.

[Stéphane le calme]

Claude Code détruit 2,5 ans de données en production en un instant :
le post-mortem qui devrait faire réfléchir tous les développeurs utilisant des agents IA

Un développeur a confié à Claude Code la gestion d'une migration d'infrastructure Terraform sur AWS. En quelques minutes, l'agent a détruit l'intégralité de son environnement de production — base de données, snapshots compris — faisant disparaître 2,5 ans d'historique de cours. L'incident, rendu public dans un post-mortem exemplaire, soulève une question que l'essor fulgurant du vibe coding ne peut plus esquiver : jusqu'où peut-on déléguer à une IA des opérations irréversibles sur des environnements de production ?

Il est environ 22 heures, un jeudi soir de fin février, quand Alexey Grigorev s'installe devant son nouveau PC pour reprendre une tâche qu'il juge somme toute banale : migrer le site statique AI Shipping Labs de GitHub Pages vers Amazon Web Services, en le faisant cohabiter avec l'infrastructure existante de DataTalks.Club, sa plateforme de gestion de cours hébergeant plusieurs années de soumissions d'étudiants.

Pour l'aider, il a recours à Claude Code, l'agent de développement en ligne de commande d'Anthropic. Et pour gérer l'infrastructure cloud, il utilise Terraform, l'outil de référence en matière d'Infrastructure-as-Code, capable d'approvisionner ou de détruire des environnements entiers AWS en une seule commande. Un marteau puissant, donc. Et Grigorev le tient d'une main légère.

Le plan de migration, en soi, était raisonnable : déplacer le site statique vers S3, basculer le DNS vers AWS, déployer une version Django sur un sous-domaine, puis effectuer la bascule finale. Seulement, les problèmes sont venus de l'exécution.

Premier faux pas : Grigorev décide de faire tourner l'infrastructure des deux sites dans le même VPC, ce qui augmente la complexité et le risque, car toute modification de l'un peut désormais contaminer l'autre. Claude lui avait d'ailleurs déconseillé de combiner les deux configurations — mais le développeur a choisi de passer outre, estimant qu'une infrastructure séparée ne valait pas les 5 à 10 dollars d'économie mensuelle qu'elle lui ferait perdre.

Une cascade d'erreurs logiques, chacune raisonnable prise isolément

Ce qui suit illustre parfaitement ce qu'on pourrait appeler le paradoxe de l'agent autonome : chaque décision prise par Claude était, localement, correcte. C'est leur enchaînement dans un contexte mal spécifié qui a produit la catastrophe.

Grigorev avait récemment changé de machine et n'avait pas migré Terraform. Lorsque Claude a exécuté terraform plan, l'outil a supposé qu'aucune infrastructure n'existait — et a donc planifié la création de tout depuis zéro. Une longue liste de ressources à créer est apparue dans le terminal, ce qui a alerté le développeur. Il interrompt Claude, mais des ressources ont déjà été provisionnées, créant des doublons.

Grigorev demande alors à l'agent d'identifier ces ressources dupliquées et de les supprimer. Pendant ce temps, il va récupérer sur son ancien ordinateur l'archive Terraform contenant le fichier d'état (state file) — ce fichier critique qui décrit l'infrastructure telle qu'elle existe réellement à un instant T. Il la transfère sur sa nouvelle machine, et la pointe à Claude pour lui permettre de faire la différence entre ressources réelles et doublons fraîchement créés.

C'est là que le mécanisme de destruction s'enclenche. Claude a décompressé l'archive Terraform sans que Grigorev le remarque, remplaçant le fichier d'état courant par l'ancien, qui contenait toutes les informations sur la plateforme de cours DataTalks.Club. Puis, face à la complexité de distinguer les ressources dupliquées via la CLI AWS, l'agent a pris une décision qui lui semblait logique : « Je ne peux pas le faire ainsi. Je vais exécuter un terraform destroy. Puisque les ressources ont été créées par Terraform, les détruire via Terraform sera plus propre et simple. »

La logique semblait claire. La réalité, désastreuse. La commande terraform destroy a effacé la totalité de l'infrastructure de production : VPC, cluster ECS, load balancers, bastion host — et la base de données RDS contenant 2,5 ans de soumissions, devoirs, projets et classements pour chaque promotion de cours. Quand Grigorev a vérifié la plateforme DataTalks.Club quelques instants après : page blanche.

Pire encore, les snapshots automatiques quotidiens avaient eux aussi disparu, emportés dans la destruction. La console AWS montrait bien l'événement de sauvegarde créé à 00h24, mais le snapshot lui-même était inaccessible — comme si l'enregistrement de son existence avait survécu à sa suppression.

Le sauvetage : AWS Business Support à minuit

Face à l'étendue des dégâts, Grigorev a ouvert un ticket de support AWS aux alentours de minuit. Constatant que le niveau Developer offrait des délais de réponse insuffisants pour un incident de production, il a souscrit au support Business, qui garantit une heure de réponse pour les incidents critiques — au prix d'une majoration de 10 % sur sa facture AWS mensuelle, coût qu'il paiera désormais à titre permanent.

AWS Support l'a rappelé en moins d'une heure. Les ingénieurs ont confirmé que la base de données et tous les snapshots avaient bien été supprimés par les appels API de Terraform — mais qu'un snapshot subsistait de leur côté, invisible dans la console du client. Une conférence téléphonique a été organisée. Le dossier a été remonté à l'équipe interne AWS. Exactement 24 heures après la destruction, la restauration était terminée : 1 943 200 lignes dans la seule table courses_answer, et la plateforme de cours de nouveau en ligne.

Post-mortem : six mesures concrètes

Grigorev a publié un post-mortem d'une franchise rare, dans lequel il assume l'entière responsabilité de l'incident. Le dépôt GitHub qu'il a ouvert contre Claude Code n'était pas un exercice d'incrimination — c'était une documentation à destination des autres développeurs. Les mesures prises dans la foulée méritent d'être détaillées, car elles constituent un guide pratique pour tout développeur utilisant des agents IA avec des outils d'infrastructure.

1. Suppression des permissions d'exécution pour Claude Code. Le changement le plus radical : l'agent ne peut plus exécuter de commandes Terraform de manière autonome. Le workflow est désormais le suivant : Claude génère un plan, Grigorev l'examine manuellement, et c'est lui qui exécute les commandes destructives.

2. Protection contre la suppression à deux niveaux. La protection est activée à la fois dans la configuration Terraform (flag prevent_destroy) et directement dans AWS pour les ressources critiques comme la base de données RDS. Ces protections peuvent être contournées intentionnellement, mais elles créent de la friction et empêchent les destructions accidentelles.

3. Migration du state file vers S3. Terraform dispose désormais d'une vue cohérente de l'infrastructure, non plus liée à une machine locale. Le state file ne peut plus « disparaître silencieusement » lors d'un changement de machine.

4. Test de restauration quotidien automatisé. Une fonction Lambda se déclenche chaque nuit à 3h du matin, crée une nouvelle instance de base de données à partir du backup automatique, exécute une requête de vérification simple, puis stoppe l'instance — sans la supprimer. À tout moment, un réplica récemment restauré est disponible. Substack Ce mécanisme teste en permanence que les sauvegardes sont réellement restituables, un point que beaucoup d'équipes négligent.

5. Sauvegardes S3 indépendantes du cycle de vie Terraform. La leçon dure de l'incident était que les snapshots RDS avaient été supprimés avec la base de données. Les nouvelles sauvegardes S3 sont stockées séparément et ne sont pas liées à l'état d'infrastructure, avec versioning activé : supprimer un bucket nécessite d'abord de vider son contenu, ce qui ajoute une barrière supplémentaire.

6. Isolation dev/prod. Pour tout nouveau projet, Grigorev envisage des comptes AWS séparés pour le développement et la production, afin d'éviter toute contamination croisée.

Un incident isolé ou un pattern émergent ?

L'incident de Grigorev ne serait pas aussi retentissant s'il ne s'inscrivait pas dans une série préoccupante. En juillet 2025, le fondateur de SaaStr, Jason Lemkin, avait décrit comment l'agent de codage de Replit avait effacé la base de données de production d'une application en cours de développement, alors qu'un gel du code (code freeze) explicite était en vigueur et que l'IA avait été instruite de toujours demander permission avant toute action destructive. Le CEO de Replit avait dû s'excuser publiquement. Plus récemment, des pannes chez AWS ont été attribuées à des erreurs similaires commises par des agents de codage IA mal supervisés.

Le dénominateur commun de ces incidents est résumé avec précision : les agents IA sont excellents pour exécuter des commandes, mais n'ont aucune notion de blast radius — la capacité à évaluer l'étendue des dommages potentiels d'une opération avant de la lancer.

Un ingénieur DevOps expérimenté, face à un terraform destroy sur un environnement contenant deux sites distincts, aurait immédiatement identifié le risque. Claude Code, lui, a suivi la logique de son instruction avec une cohérence parfaite — et une ignorance totale du contexte organisationnel.

La leçon structurelle : l'IA comme junior, pas comme architecte

Un internaute formule la critique la plus directe : la plupart des administrateurs système, à la lecture du récit, identifieraient immédiatement les failles de base dans l'approche de Grigorev — notamment le fait d'avoir accordé des permissions étendues à ce qui est, en pratique, un subordonné, et de ne pas avoir défini des périmètres de permissions adaptés à un environnement de production. La leçon la plus fondamentale est peut-être d'avoir supposé que Claude aurait le contexte nécessaire pour comprendre ce que signifiait l'existence d'un second site — comme un administrateur système junior ne l'aurait pas eu non plus.

L'analogie avec le stagiaire est instructive. On ne confie pas à un nouvel arrivant les accès root sur la production sans supervision, même s'il paraît compétent. Les agents IA, aussi sophistiqués soient-ils, fonctionnent dans les limites de ce qu'on leur a transmis — et un fichier d'état Terraform ne raconte pas l'histoire complète d'une infrastructure, ni ses dépendances humaines, organisationnelles, ou contractuelles.

L'incident ne démontre pas que les outils de codage IA sont intrinsèquement dangereux. Il illustre comment une automatisation puissante peut amplifier les erreurs opérationnelles. Plus les agents IA gagnent en autonomie, plus les garde-fous standard du DevOps — protection contre la suppression, state remote, test de restauration, moindre privilège — deviennent non négociables.

La bonne nouvelle : les protections de base du DevOps ne sont pas optionnelles simplement parce que l'opérateur est un agent IA. Si quoi que ce soit, elles sont encore plus importantes. Et l'incident de Grigorev, par sa transparence et la qualité de son post-mortem, aura au moins eu le mérite de le rappeler avec éclat.

Source : Alexey Grigorev

Et vous ?

La faute à qui ? Claude avait lui-même déconseillé la mutualisation des infrastructures — et Grigorev a passé outre. Dans quelle mesure la responsabilité de ce type d'incident doit-elle être partagée entre l'utilisateur, l'outil et le fournisseur de l'agent IA ?

Peut-on vraiment parler d'agents « autonomes » ? Si l'efficacité d'un agent IA repose entièrement sur la qualité du contexte que lui fournit l'humain, n'est-ce pas surtout l'automatisation des erreurs humaines que l'on accélère, plutôt que leur prévention ?

Le vibe coding en production : ligne rouge ou nouvelle norme ? De plus en plus de développeurs délèguent à des agents IA des tâches sur des environnements vivants. Où devrait-on tracer la limite entre ce qu'un agent peut exécuter seul et ce qui doit impérativement passer par validation humaine ?

Les standards DevOps sont-ils suffisants pour l'ère agentique ? La protection contre la suppression, le state remote, les backups hors Terraform — ces bonnes pratiques existaient bien avant Claude Code. Faut-il des garde-fous spécifiquement conçus pour les agents IA, ou la discipline DevOps classique suffit-elle ?

Voir aussi :

Le PDG de Replit présente ses excuses après l'effacement par son agent IA de la base de code d'une entreprise et de précédents propos selon lesquels l'IA mettra les humains au rebut dans la filière

La directrice de la sécurité IA chez Meta permet à un agent IA de supprimer accidentellement sa boîte de réception, OpenClaw efface la boîte de réception malgré des commandes répétées pour l'arrêter

Des tests révèlent les lacunes profondes du compilateur C créé par l'IA Claude d'Anthropic pour 20 000 dollars : l'outil est nettement moins efficace que GCC et peine à réaliser des optimisations de base

Une faille dans le nouvel agent de codage Gemini CLI de Google aurait pu permettre à des pirates informatiques d'exfiltrer des données ou d'exécuter du code malveillant arbitraire sur la machine ciblée

L'IA peut-elle remplacer des développeurs professionnels ? Gemini CLI de Google et Replit ont commis des erreurs qui ont entraîné la suppression des données, inventant des répertoires, falsifiant des tests

[bimbo9991]

Il y a 6 mois, j'ai eu le même problème avec Claude code. Il a effacé toutes mes bases de données. Mais heureusement que j'avais des sauvegardes de côté. Des sauvegardes très récentes Depuis Je ne lui autorise plus d'aller dans la base de données. Pourquoi j'utilise claude ? Juste pour le scannage Pour trouver des failles dans mes fichiers dans ma base de données. L'astuce est de bien bien expliquer ce qu'il doit faire, mais de lui demander de répéter ce qu'il doit faire avant de l'autoriser.

[_toma_]

La capture d'écran est épique et m'a bien fait rire (même si, lui, ça a pas dû le faire rire).

[vertex.3F]

Cet exemple, montre que l'IA ne sait qu'écrire du code et encore mal. D'ailleurs la plus grande valeur ajoutée d'un logiciel n'est pas le code mais toute l'analyse et les méthodes algorithmiques qui l'accompagnent.

Il faut une véritable analyse faite par un être humain qui permettra ensuite à l'IA d'avancement vers l'objectif final.

L'IA est et reste donc une machine virtuelle comme toute autre machine appelée vulgairement "smart system". Pour que cela fonctionne, il lui faut des instructions.
Dit d'une autre manière il faut qu'un être humain lui crée un mode d'emploi appelé ALGORITHME. CQFD

Donc l'IA n'est qu'un assistant...

oui, je le pense aussi


source https://www.commitstrip.com/fr/2016/...-precise-spec/

[disedorgue]

Juste une remarque comme ça, en passant: lorsque l'humain n'automatise pas ces taches récurrentes, vous pensez que c'est par flemmardise ou parce qu'il aime bien faire du récurrent ?

Et dans le contexte qui nous intéresse ici, pourquoi le monsieur, avant l'avènement de l'ia agentique, il ne donnait pas la main au premier venu pour faire l'OP ?

Pour moi, dans son post mortem, il manque le Point 1: Arrêter d'être crétin.

L'IA à la connaissance mais pas de cerveau contrairement au premier venu qui lui n'a peut-être pas la connaissance requise mais à un cerveau,ce qui en principe, devrait aider à lever certain garde fou.

Bon après, il est vrai que certain ont du mal à l'utiliser mais au moins, ils en ont un et ça permet de les responsabiliser