Au-delà du « Vibe Coding » : les meilleures pratiques en 2026

Dans cet article, vous découvrirez les bonnes pratiques de programmation en IA, les flux de travail et les modèles d'ingénierie agentique utilisés par de véritables équipes en 2026.

Introduction

Au cours des huit derniers mois, j’ai progressivement quitté Tel-Aviv pour m’installer à New York. Ce changement en valait la peine, mais je n’arrivais plus à suivre le tourbillon hebdomadaire des nouvelles tendances en matière de programmation IA.

Et dans le domaine du développement d'IA, huit mois, ça donne l'impression d'une décennie.

La dernière fois que j'ai sérieusement mis à jour mon flux de travail, c'était vers décembre 2025. J'utilisais Windsurf avec Cascade (qui s'appelle désormais Devin), puis je suis passé aux modèles Claude, et la principale conclusion à l’époque avait été de mettre en place un fichier CLAUDE.md très strict : planifier d’abord, privilégier la simplicité des modifications, écrire des tests, exécuter les tests, ne pas négliger l’analyse des causes profondes.

La règle la plus utile était aussi la moins prestigieuse :

Commencez par analyser le problème, lisez les fichiers pertinents, puis rédigez une liste de contrôle pour tasks/todo.md avant de commencer à coder.

Ce simple changement a vraiment donné un coup de fouet à mon travail de développement. Mes sessions sont restées ciblées, les « hallucinations » liées aux agents ont considérablement diminué, et j'ai pu traiter les tickets beaucoup plus rapidement.

Je voulais donc savoir : « Quels nouveaux superpouvoirs sont apparus au cours des six derniers mois ? »

J’ai passé une journée à faire ce que la plupart des développeurs font sans doute aujourd’hui lorsqu’ils ont besoin de se mettre rapidement à jour : j’ai demandé à Claude, Grok et ChatGPT de rechercher les dernières tendances en matière de programmation IA, puis je les ai mis en débat les uns contre les autres. Mais je ne cherchais pas la démo la plus récente. Je voulais savoir ce qui avait réellement fait ses preuves.

J'ai ensuite vérifié la validité de ces résultats auprès d'une quinzaine de personnes dont j'apprécie le jugement : des directeurs techniques, des fondateurs de start-ups, des chercheurs en IA, des responsables backend, des chefs d'équipe et des ingénieurs seniors qui utilisent ces outils sur des bases de code réelles.

Voici ce que j'ai trouvé.

Share the AI coding workflows and practices that have proven useful in production.J'aimerais beaucoup en savoir plus sur votre méthode de travail en programmation. Merci de répondre à ce .

Du « Vibe Coding » à l’« Agentic Engineering »

Chaque jour, de nouvelles démos très convaincantes font leur apparition sur les réseaux sociaux. « Ce framework va décupler les performances de vos agents ! » « Si vous n’utilisez pas ce nouvel outil, vous êtes déjà à la traîne ! » Mais il est difficile de distinguer le vrai du faux.

« Vibe coding », cette expression Andrej Karpathy a popularisée début 2025, a révolutionné le développement logiciel : coder en décrivant son intention, accepter les modifications générées et ajuster le modèle jusqu’à ce que l’application fonctionne. On a du mal à croire qu’on ait jamais procédé autrement. Le Collins Dictionary l’a élu « mot de l’année 2025 ». Mais les équipes de production sérieuses ont désormais dissocié deux concepts qui étaient auparavant indissociables : l’utilisation de l’IA pour générer du code, et l’acceptation de ce code généré par l’IA sans structure ni vérification suffisantes.

Le premier est là pour rester. Le second, c'est le problème. Une analyse de CodeRabbit portée sur 470 pull requests réelles issues de GitHub a révélé que le code co-écrit par l’IA contenait environ 1,7 fois plus de problèmes que le code écrit par des humains, avec des failles de sécurité jusqu’à 2,7 fois plus nombreuses. Le code fonctionne. Mais il nécessite plus de vigilance que jamais.

C'est le passage du « vibe coding » à ce que l'on pourrait appeler l'ingénierie agentique. L’agent peut inspecter des fichiers, écrire du code, exécuter des commandes, générer des tests, déboguer les défaillances et analyser ses propres résultats. Mais il faut tout de même mettre en place un processus d’ingénierie autour de lui. Surtout si la production vous tient à cœur.

Ce que font réellement les vraies équipes

Le battage médiatique autour des réseaux sociaux donne l'impression que tout le monde met constamment à jour son flux de travail : des pipelines axés sur les spécifications, multi-agents, orchestrés dans le cloud, connectés via MCP et entièrement autonomes.

J'ai donc demandé à un petit groupe d'amis, certes restreint mais solide, assumant des responsabilités importantes, ce qu'ils faisaient. La plupart d'entre eux se livraient à des activités plus simples que ce que l'on pourrait croire en parcourant Internet : un agent de codage performant, une étape de planification, un fichier d'instructions pour le dépôt, des tests, une révision manuelle, des changements occasionnels de modèle et, parfois, un deuxième modèle pour les exercices de « red teaming ».

Un directeur technique l'a formulé ainsi :

« Il faut toujours planifier à l'avance. Ne vous contentez jamais de dire “fais ça”, même pour les petites tâches, sinon ils passeront à côté de certaines choses. »

Un chef d'équipe a déclaré :

« Planifiez jusqu’à ce que tout soit parfait, puis passez à la réalisation. Rien de compliqué. »

Une ingénieure senior full-stack a quant à elle décrit son approche « zero-trust » :

« Je lui fais créer des tests, puis je lui fais tester ses propres tests. Ensuite, je fais intervenir un autre agent de la « red team ». Et enfin, je procède à des tests manuels. Dès qu’il s’agit d’argent ou du cycle de vie, je passe toujours par des tests manuels. »

Votre tâche principale consiste désormais à planifier

Il apparaît désormais clairement que la responsabilité principale de l’humain consiste désormais à collaborer avec l’agent pour élaborer un plan parfait. Mon manuel tasks/todo.md a désormais des noms plus sophistiqués.

Le développement axé sur les spécifications est la méthode « propre » : on part d’une intention, on la transforme en spécification, on élabore un plan de mise en œuvre, on le décompose en tâches, et ce n’est qu’ensuite que l’on laisse l’agent coder. Le Spec Kit de GitHub a formalisé cette approche sous le nom de spec.md, plan.mdet tasks.md. AWS Kiro utilise les spécifications comme artefacts structurés à des fins de suivi et de responsabilité.

On retrouve cette même idée dans les outils. Claude Code dispose d’un paramètre /goal, qui indique à Claude de continuer à travailler jusqu’à ce qu’une condition de réussite vérifiable soit remplie : tous les tests sont réussis, toutes les erreurs TypeScript sont résolues et la migration est terminée. En arrière-plan, un modèle d’évaluation léger vérifie après chaque itération si l’objectif est objectivement atteint, de sorte que l’agent effectue des boucles de manière autonome jusqu’à ce qu’il converge ou atteigne une limite de budget. Codex a intégré ce même concept, avec des états tels que poursuivre, « en pause », réaliséet les contraintes budgétaires qui persistent après le redémarrage de la session.

Il s'agit de la version « produit » d'un tasks/todo.md: un objectif durable vers lequel l'agent peut revenir, avec désormais davantage d'autonomie autour de celui-ci.

C'est aussi là que l'autonomie devient coûteuse. Si la condition de « fin d'exécution » est floue, l'agent peut rester en boucle pendant longtemps sans pour autant agir correctement. L'autonomie sans garde-fous n'est qu'un moyen plus rapide de gaspiller de l'argent.

Pour les tâches complexes, l'agent doit se poser trois questions avant de modifier le code : Que modifions-nous ? Quels fichiers et comportements sont concernés ? Comment saurons-nous que cela a fonctionné ?

Le développement piloté par les tests (TDD) a toujours été prôné comme une vérité absolue, mais il était bien moins souvent mis en pratique. Aujourd’hui, avec le « codage agentique », investir dans les tests est l’une des principales missions du développeur. Un directeur technique, parmi les premiers à avoir adopté cette approche, m’a confié : « Je passe un certain temps à peaufiner le plan. Pour chaque fonctionnalité que je développe, je fais en sorte qu’elle fasse l’objet de tests très complets. Ainsi, je sais qu’elle fonctionnera une fois terminée. »

Si l'agent ne peut pas noter cela, cela signifie que ce n'est pas prêt à être codé.

AGENTS.md, compétences et rotation contextuelle

Mon ancien processus de travail reposait sur un gros fichier CLAUDE.md . Je l’avais rempli de règles et de mises en exergue : NE SOIS PAS PARESSEUX. NE SAUTE JAMAIS DE TESTS. REND TOUT AUSSI SIMPLE QUE POSSIBLE. L’objectif était de m’assurer que l’agent reste discipliné et ne prenne pas de raccourcis.

Et ce type de recommandations a porté ses fruits. En 2025, tous les fournisseurs d’agents disposaient d’une version ou d’une autre d’instructions au niveau du repo : Claude Code, Codex, Cursor, Copilot, Windsurf. Le secteur a commencé à s’aligner sur la norme AGENTS.md: un guide au niveau du dépôt qui indique à l’agent les règles de base du projet.

Mais les utilisateurs ont commencé à surcharger leurs fichiers Claude, ce qui a eu des conséquences. Une étude de l’ETH Zurich datant de février 2026 a comparé des fichiers d’instructions de référentiels à de véritables tickets GitHub et a constaté que les fichiers de contexte surchargés n’amélioraient souvent pas la réussite des tâches et pouvaient augmenter le coût d’inférence de plus de 20 %.

Il s'avère que l'agent ne devient pas plus discipliné pour autant que vous lui répétiez trois fois la même consigne en criant. En fait, vous ne faites généralement que gaspiller des jetons et occulter les règles qui comptent vraiment.

Le nouveau mode de défaillance est la « context rot ». Un mauvais AGENTS.md est pire que l’absence de fichier AGENTS.md , car l’agent obéira sans hésiter à des instructions obsolètes.

Le secteur a donc divisé ce concept en deux. AGENTS.md doit rester concis. Il répond à la question suivante : quelles sont les règles et les conventions spécifiques à ce projet ?

Pour tout le reste, il y a les « Skills ». Un « Skill » est une référence chargée à la demande pour une tâche spécifique : comment ajouter un nouveau point de terminaison API, comment effectuer une migration de base de données, comment rédiger une liste de contrôle de mise en production. Le « Skill » ne se charge que lorsque l’agent reconnaît le schéma correspondant et en a besoin.

Concrètement, cela donne ceci :

Votre AGENTS.md indique :

Exécuter les tests avec npm test. Vérifiez toujours le code avant de le fusionner. Utilisez la compétence Webhook lorsque vous ajoutez de nouvelles intégrations.

La Skill « webhook » indique :

Créez la route, ajoutez les types, écrivez le gestionnaire, traitez les cas de réussite et d'échec, puis mettez à jour la documentation.

L'agent n'a pas besoin d'exécuter chaque procédure dans un contexte « toujours actif ». Elle reste dans la Skill. Votre AGENTS.md reste concis. Et si la procédure du webhook change, il suffit de mettre à jour la Skill une seule fois.

Règle générale : conservez AGENTS.md simple et concis. Créez une Skill lorsque vous avez une procédure récurrente que vous vous retrouvez à expliquer sans cesse. Et traitez les instructions du dépôt comme du code : relisez-les, supprimez les règles obsolètes et ne les laissez pas se dégrader.

MCP et CLI

Le protocole MCP (Model Context Protocol) était sans doute le terme le plus en vogue dans le monde des développeurs en 2025. Le concept était solide : une méthode standardisée pour intégrer des applications, au lieu d’avoir à écrire du code de liaison sur mesure pour chaque outil.

Alors bien sûr, en 2026, « le MCP est mort ». Ce n'est pas vrai. Mais son utilisation est devenue plus nuancée.

Un directeur technique que j'ai interrogé l'a dit sans détour :

« Les modélisateurs ne s'appuient presque plus sur MCP. Ils sont devenus incroyablement doués pour utiliser uniquement l'interface en ligne de commande. »

Le problème principal réside dans la surcharge. Un serveur MCP standard peut charger une grande quantité de schémas d'outils dans le contexte avant même que l'agent ne commence à effectuer des tâches utiles. Les outils en ligne de commande sont locaux, modulables, et les modèles s'adaptent déjà très bien aux workflows de type Unix : commandes, options, pipes, sortie JSON, journaux.

Mais les agents ne découvrent pas les CLI comme par magie. Ils ont besoin d'instructions, mais d'instructions plus succinctes.

S'il s'agit d'une interface en ligne de commande (CLI) bien connue comme aws, gh, gcloud, ou docker, l’agent le sait probablement grâce à son apprentissage. Vous pouvez lui indiquer : « Ce projet utilise l’interface CLI AWS. Tu disposes d’identifiants. Utilise-la pour l’infrastructure. » Et l’agent se charge généralement du reste.

S'il s'agit d'une interface CLI personnalisée ou interne, créez une Skill. Un paragraphe expliquant la commande, les options et le format de la sortie suffit généralement.

La question pertinente concernant le MCP n'est pas « Le MCP est-il mort ? », mais « Quelles autorisations venez-vous d'accorder à un appelant d'outils probabilistes ? »

Le MCP est pertinent lorsque l'agent a besoin d'un accès contrôlé à des systèmes externes : documentation, tickets, observabilité, bases de données, API. Mais si une interface en ligne de commande (CLI) permet d'effectuer cette tâche en toute sécurité, commencez par là. Si la même procédure via la CLI se répète, transformez-la en « Skill ». N’hésitez pas à recourir au MCP lorsque ces deux options ne suffisent pas, et traitez chaque serveur MCP comme une infrastructure de production : principe du moindre privilège, validations, journalisation et audit de sécurité.

A popular meme highlighting how AI agents have changed the day-to-day experience of software engineering, often shifting the role from implementation toward orchestration and oversight.

Les agents deviennent des avions de contrôle

Le changement majeur de 2026 réside dans le fait que les agents de codage ne sont plus simplement des fenêtres de discussion rattachées à un éditeur. Ils deviennent des plans de contrôle.

Claude Code a /objectif, des hooks, des sous-agents, des sessions en arrière-plan et des vues d’agent. Codex propose une interface en ligne de commande (CLI), le cloud, une application, des arborescences de travail, la révision de code et la supervision mobile. GitHub Copilot peut transformer les tickets en pull requests et réviser le code. Google Antigravity est conçu pour gérer les agents dans différents espaces de travail.

L'interface passe d'un mode « discuter avec un modèle » à un mode « gérer une file d'attente de travailleurs semi-fiables ».

Ça a l'air futuriste, mais la leçon pratique est ennuyeuse : chaque agent a besoin d'une mission claire, d'un périmètre d'action restreint, d'un moyen de prouver que ça a fonctionné, et d'une personne responsable de la fusion.

C'est là que les agents à exécution prolongée s'avèrent utiles.

Imaginez que vous ayez une liste de 30 dépendances à mettre à jour. Normalement, vous devriez vous asseoir avec l'agent, lui demander de vous présenter chacune d'entre elles, examiner chaque modification et approuver chaque fusion. Cela prend des heures et vous immobilise.

Un agent fonctionnant en continu peut parcourir la liste : mettre à jour une dépendance, exécuter les tests, corriger les échecs, passer à la suivante, puis s'arrêter lorsque tous les tests ont réussi.

C'est un bon cas d'utilisation, car « terminé » est objectivement vérifiable.

Exemples de cas où les agents à exécution longue sont réellement utiles : mises à jour des dépendances, nettoyage après les tests, génération de documentation, exemples de SDK, tâches de recherche ou éléments du backlog assortis de critères d’acceptation très clairs, tels que « tous les tests réussis », « lint clean » ou « migration terminée ».

Lorsqu’elles échouent de manière spectaculaire : facturation, authentification, autorisations, migrations, suppression, conformité, ou tout ce qui touche aux données des clients ou à leur cycle de vie. Ces situations exigent de faire preuve de discernement. « Cette migration est-elle sûre ? » n’est pas une question à laquelle on répond par oui ou par non. Pas plus que « Devrions-nous supprimer cela ? »

La règle : n’utiliser des agents s’exécutant en arrière-plan que pour les tâches dont l’achèvement est objectivement vérifiable et dont l’impact en cas de défaillance est limité. Pour tout le reste, on s’en tient au rythme humain.

Si vous gérez vous-même des agents, tmux reste l'astuce un peu rébarbative qui vous sauve la mise. Les agents qui s'exécutent sur une longue durée s'arrêtent lorsque votre connexion SSH est interrompue. Un multiplexeur de terminaux maintient la session active, résiste aux déconnexions et vous permet de consulter l'historique de ce qui s'est passé.

Mais tmux est une solution de secours à monter soi-même, pas la tendance principale. La véritable tendance, c’est que les outils intègrent désormais ce modèle : sessions en arrière-plan, tableaux de bord d’agents, arborescences de travail isolées, validations à distance et files d’attente de révision.

Les agents persistants dépourvus de critères de réussite vérifiables ne sont rien d'autre que des hallucinations plus longues et plus coûteuses.

Il existe également une catégorie parallèle de moteurs d’agents personnels toujours actifs, comme OpenClaw et Hermes. Ils sont intéressants en tant que plans de contrôle autour du travail de codage : acheminement des messages, surveillance des sessions, envoi d’alertes et, éventuellement, répartition des tâches. Mais ils ne constituent pas encore le cœur du flux de travail de codage. Cela vaut la peine de les suivre et de les tester, mais n’ayez pas l’impression que tout le monde dispose de son propre agent OpenClaw. Aucun des 15 pionniers que j’ai interrogés n’en avait configuré.

Le choix du modèle a moins d'importance

La première question qu’un responsable de la recherche en IA m’a posée lorsque j’ai évoqué mon processus de travail ne portait ni sur les outils ni sur les frameworks. Elle était la suivante :

« Quel est ton budget pour les jetons ? »

C'est ce qui distingue l'ingénierie de la programmation. Bien sûr, avec les agents d'IA, si l'on consacre suffisamment d'argent et de temps à un problème, on peut probablement le résoudre. Ainsi, désormais, chaque décision relative au flux de travail dépend en grande partie du budget. Et les différents agents ont une incidence sur ce budget.

Certaines personnes à qui j'ai parlé ne jurent que par Codex. D'autres préfèrent Claude. Les utilisateurs de Cursor apprécient de pouvoir changer de modèle. Certains utilisent Copilot simplement parce que c'est l'outil fourni par leur entreprise.

L'un des fondateurs m'a confié qu'il « développait des fonctionnalités à la chaîne, comme une bête » grâce à Codex. Un autre avait un point de vue plus nuancé :

« Codex est incroyablement performant pour tout ce qui touche au calcul. Claude a quand même plus de goût. »

Mais les conseils plus posés d'un directeur technique se sont avérés plus utiles :

« Ne vous cantonnez pas à un seul modèle. Toutes les deux semaines, l'un perd de sa valeur, tandis qu'un autre gagne en qualité. »

Ce principe éprouvé est celui de l'hygiène des modèles : utilisez un modèle robuste pour la planification et les raisonnements complexes, des modèles moins coûteux pour les modifications simples, un deuxième modèle pour les révisions à haut risque, ainsi que des instructions transférables afin qu'un autre modèle ou une autre session puisse reprendre le travail.

Cela revêt d'autant plus d'importance que la tarification évolue vers une facturation à l'utilisation. La stratégie gagnante ne consiste pas à « utiliser le modèle le plus sophistiqué pour tout », mais à savoir quand un raisonnement coûteux en vaut la peine.

La vérification est désormais votre autre tâche principale

Lorsque le code devient peu coûteux, vérifier qu’il fonctionne et qu’il est de bonne qualité revient cher. Ce n’est pas un argument contre l’utilisation de l’IA pour coder. C’est un argument contre la mise en production d’un code que l’on ne peut pas expliquer.

Heureusement, les outils rattrapent leur retard. Les « hooks » sont des scripts déterministes qui se déclenchent lors d’événements liés aux agents. Ils permettent aux équipes de rendre certaines vérifications obligatoires. Un hook PostToolUse peut exécuter automatiquement un lint ou un contrôle de types après chaque modification de fichier, détectant ainsi les problèmes en cours d’exécution plutôt qu’à la fin. Un hook peut empêcher l’agent de déclarer prématurément la tâche terminée. Il s’agit de garde-fous qui ne dépendent pas du jugement du modèle, et pour les tâches de longue durée ou autonomes, cette distinction est importante.

Voici à quoi pourrait ressembler un bon cycle de révision :

1. Demandez à l'agent de rédiger ou de mettre à jour les tests.

2. Demandez à l'agent d'exécuter la suite de tests correspondante.

3. Utilisez un deuxième modèle pour simuler des attaques (red team) sur les modifications importantes.

4. Tester manuellement les chemins à haut risque.

Une indication utile avant l'examen par un humain :

Vérifiez les modifications que vous avez apportées.
Repérez les bugs potentiels, les tests manquants, les cas limites, les problèmes de sécurité ou toute complexité inutile.
Ne modifiez pas encore les fichiers. Signalez d'abord vos constatations.

L'aspect sécurité de cette question revêt une importance encore plus grande. Dès lors que les agents peuvent commenter les PR, exécuter des workflows, utiliser des outils et accéder aux identifiants, l'injection de messages cesse d'être un problème lié aux chatbots pour devenir un problème de CI/CD.

C'est justement cet aspect que, selon moi, de nombreuses équipes sous-estiment encore. Si l'agent analyse un ticket, une description de PR, un commentaire de code ou un journal des modifications d'une dépendance, il traite des données non fiables. S'il dispose en outre des autorisations nécessaires pour exécuter des commandes ou accéder à des secrets, cela crée alors une surface d'attaque.

C'est pourquoi les règles, même si elles peuvent paraître ennuyeuses, revêtent d'autant plus d'importance : principe du moindre privilège, isolation en bac à sable, validations, modifications mineures, vérifications déterministes, journaux d'Audit et responsabilité humaine.

Si je devais créer un nouveau dépôt aujourd'hui

1. Créer un site AGENTS.md contenant des commandes d'installation, de test et de vérification de type, des règles de workflow et une définition de « terminé ». Restez concis. N'ajoutez des règles que lorsque l'agent rencontre réellement un échec, et non à titre préventif.

   • Les tâches complexes nécessitent une planification rigoureuse. Avant de se lancer dans le codage, l’agent rédige une liste de contrôle pour tasks/todo.md en précisant l'objectif, les fichiers concernés, les étapes et les risques.

   • Archiver les plans finalisés dans le dossier tâches/archive/. Ces plans constituent l'historique de ce que l'agent pensait faire et des raisons qui le motivaient.

   • Une tâche par instruction, un problème par modification. Les petites modifications peuvent être vérifiées. Les modifications importantes masquent des bogues.

   • Aucun changement de comportement ne peut être mis en œuvre sans test préalable. Si l'agent affirme qu'« aucun test n'est nécessaire », insistez.

2. Créez une compétence la troisième fois que vous expliquez quelque chose. La première fois que vous guidez l'agent à travers une procédure, contentez-vous de l'expliquer. La deuxième fois, notez les éléments qui se répètent. La troisième fois, créez un fichier SKILL.md.

3. Utiliser l'interface CLI par défaut. N'ajouter MCP que lorsque l'agent a besoin d'un accès contrôlé à un système externe et que le chemin d'accès CLI ne suffit pas.

4. N'utilisez les agents à exécution longue que pour les tâches dont l'achèvement peut être vérifié de manière objective. Mises à jour des dépendances, nettoyage des tests, documentation, corrections de lint ? Bien sûr. Facturation, authentification, migrations, suppression ? Non.

5. Analyse des différences à haut risque par la « red team » à l'aide d'un deuxième modèle. Avant de fusionner tout élément touchant à la sécurité, aux paiements, aux autorisations ou au cycle de vie des données, demandez à un autre modèle de détecter d'éventuels problèmes.

6. Faites ce qui incombe à l'humain. Vérifiez vous-même les différences. Lancez l'application. Testez manuellement les chemins à risque. L'agent fait des propositions. C'est vous qui décidez.

Conclusion

Ces recherches m'ont permis de me calmer. Les bonnes pratiques ne sont en réalité que différentes déclinaisons d'une vérité immuable : respecter les principes SOLID, privilégier le TDD et rédiger des spécifications détaillées avant de se lancer dans le développement.

Le meilleur processus de développement IA ne remplace pas l'ingénierie logicielle. Il s'agit en réalité d'ingénierie logicielle menée par un développeur junior bien plus rapide, qui ne se fatigue jamais, a parfois des hallucinations, casse de temps en temps tout ce qu'il touche et a besoin d'instructions très claires.

Si vous l'abordez ainsi, ces outils sont incroyables. Si vous les considérez comme de la magie, vous finirez par devoir déboguer cette magie.

Qu'est-ce que tu utilises ?

C'est ma première tentative pour rattraper mon retard. J'aimerais maintenant avoir l'avis de ceux qui utilisent réellement ces outils dans leur travail. À quoi ressemble votre processus de développement en IA à l'heure actuelle ?

Utilisez-vous Cursor, Claude Code, Codex, Copilot ou un autre outil ? Avez-vous essayé Skills, MCP, les sous-agents, les arborescences de tâches, /goal, les hooks ou les agents à exécution longue ? Qu'est-ce qui a fonctionné ? Qu'avez-vous abandonné ?

Merci de me le faire savoir sur cette publication LinkedIn.

A LinkedIn post asking developers how their AI coding workflows have evolved in 2026, including questions about planning, guardrails, and emerging agentic practices.Je vais m'appuyer sur les meilleures réponses pour rédiger un prochain article dans lequel je testerai les méthodes de travail les plus importantes dans le cadre de véritables projets utilisant l'API Vonage : agents parallèles, planification axée sur les spécifications, lean AGENTS.md et les compétences, MCP vs CLI, ainsi que les boucles de vérification permettant de détecter les véritables bugs.

Je vous ferai part des résultats dans le prochain article.