Évolution du rôle des développeurs à l’ère du codage par IA : d’exécutants du code à concepteurs du contexte, de la validation et de la mise en produit

baeba · 2026-07-06T10:13:13+09:00

Résumé Thèse principale Alors que l’IA atteint un niveau où elle peut écrire, modifier et tester directement du code, le rôle des développeurs se déplace du simple codage vers la définition des problèmes, la conception des tâches, la validation, la gestion du contexte et l’accompagnement de la mise en produit. Causes structurelles L’IA a fortement accéléré la production de code, mais du code ne devient pas automatiquement un bon produit. Les domaines hors codage, comme les exigences, la documentation, les tests, la structuration, les choix d’UX et la maintenabilité, gagnent encore en importance. Principaux exemples Une expérience consistant à permettre à l’IA d’exécuter jusqu’aux tests navigateur via Playwright. Une expérience de spécification de tâches répétitives sous forme de commandes, de skills et de workflows. Le cas d’un prototype frontend créé par IA, excellent en apparence mais fragile dans sa structure interne. Pistes de solution Ne pas confier seulement le code à l’IA, mais concevoir avec elle les procédures et les critères de tout le processus de développement. Les développeurs doivent relire les livrables de l’IA, conserver le contexte et organiser la structure pour qu’ils puissent déboucher sur des produits durables. Introduction Le tournant de l’ère du codage par IA L’article part de la question suivante : « Que doivent faire les développeurs à une époque où les humains ne codent plus directement ? » L’auteur estimait auparavant que, puisque l’IA produisait des hallucinations et des erreurs, la décision finale devait revenir aux humains. Mais avec les progrès récents des modèles d’IA, il estime que l’IA a atteint un niveau où elle peut comprendre les issues, explorer les fichiers, modifier le code et même faire passer les tests. Ce changement amène les développeurs à aller au-delà d’un simple usage de l’IA comme outil d’assistance, et à réfléchir à la manière de lui faire exécuter le processus de développement lui-même. Problématique centrale L’IA est devenue capable de bien écrire du code, mais cela ne signifie pas que le rôle des développeurs disparaît. Au contraire, plus le codage s’automatise, plus les autres composantes du développement deviennent visibles. La clarification des exigences, l’enregistrement des décisions, la conception des tests, la gestion de la structure du code et la revue de l’expérience produit émergent comme des tâches centrales des développeurs. Développement 1. L’IA est passée d’outil d’écriture de code à acteur d’exécution des tâches L’auteur considère que l’IA a dépassé le stade de la simple génération de fragments de code et peut désormais traiter de véritables flux de travail de développement. Auparavant, les humains devaient surveiller et corriger en permanence les résultats de l’IA ; désormais, il devient possible de lui confier des tâches puis d’en vérifier les résultats. L’amélioration des performances sur des benchmarks comme SWE Bench est mentionnée comme un indicateur de cette évolution. Le changement clé n’est plus de se demander « l’IA peut-elle écrire du code ? », mais « jusqu’où peut-on confier du travail à l’IA ? ». 2. Quand l’IA échoue, le problème n’est pas seulement un « manque de capacité » L’IA ne réussit toujours pas à tous les coups. Il arrive que des erreurs se répètent, ou que l’IA affirme avoir corrigé un problème alors que celui-ci subsiste à l’écran. Au début, l’auteur réagissait en copiant les erreurs pour les transmettre à l’IA. Puis, en utilisant Playwright pour faire ouvrir le navigateur et exécuter les tests directement par l’IA, il a compris que les procédures de validation jusque-là effectuées par des humains pouvaient elles aussi être confiées à l’IA. Ce cas montre qu’une partie de ce que l’on prenait pour des limites de l’IA provenait en réalité du fait que l’utilisateur ne lui avait pas donné les bonnes instructions. 3. Une approche AI Native consiste à déléguer l’ensemble de la procédure L’auteur quitte la perspective où l’IA n’est qu’un simple outil d’assistance et s’oriente vers une approche où l’IA exécute l’ensemble des procédures qu’il effectuait lui-même. Il transforme les tâches répétitives en commandes, skills et workflows, et tente de formaliser son savoir tacite. Il crée par exemple des flux de commandes comme /plan, /prd, /debug, /refactor, /verify et /retrospect. Le point important n’est pas simplement de dire à l’IA « écris le code », mais de définir des règles indiquant quand poser des questions, quand s’arrêter et quand valider. Cela conduit les développeurs à transformer leurs méthodes de travail et leurs critères de décision en structures réutilisables par l’IA. 4. Les savoir-faire individuels sont rapidement absorbés par les fonctionnalités des outils Les commandes et workflows que l’auteur créait lui-même finissent, avec le temps, par apparaître sous forme de fonctionnalités et de concepts officiels comme les skills, la memory, les hooks et l’orchestration. Plus une méthode d’utilisation de l’IA découverte par un individu est efficace, plus elle est rapidement absorbée par des fonctionnalités produit ou des méthodes communes. Il est donc difficile de créer une différenciation durable avec un simple prompt ou une astuce spécifique pour mieux utiliser l’IA. Ce qui compte, plus que la méthode elle-même, c’est de l’avoir appliquée à de vrais problèmes, d’avoir vu jusqu’où elle permettait d’aller et quelles limites elle révélait. 5. L’IA augmente la taille des problèmes que les développeurs peuvent traiter L’IA permet à l’auteur d’expérimenter concrètement de grandes idées qu’il n’aurait pas pu tenter auparavant en raison du coût et du temps nécessaires. Il crée rapidement, par exemple, des outils permettant de déployer code et documents comme sur un canvas, des visualiseurs MD, des outils d’analyse de code et des assistants de développement. L’essentiel n’est pas que l’IA fournisse immédiatement un produit fini, mais qu’elle abaisse la barrière au démarrage. Les développeurs passent ainsi de « pourrais-je créer cela ? » à « jusqu’où puis-je déjà aller en l’essayant ? ». 6. Traiter de grands problèmes fait apparaître les tâches de développement hors codage Lorsque le volume de code produit par l’IA augmente, il devient difficile pour les développeurs de lire tout le code eux-mêmes et d’en garder le contexte en tête. Quand on code directement, le contexte, les décisions et la compréhension structurelle s’accumulent naturellement ; lorsqu’on confie le codage à l’IA, ils ne sont pas automatiquement conservés. Les documents, les tests, les issues, les rapports de travail et l’enregistrement des raisons des changements deviennent donc importants. Il ne s’agit pas de tâches de gestion, mais de mécanismes essentiels pour préserver le contexte de développement à l’ère de l’IA. L’auteur souligne que la capacité à préserver le contexte et le jugement devient aussi importante que la capacité à coder. 7. Plus de commits et de tests ne signifie pas forcément un meilleur produit Avec l’IA, le nombre de commits, de fichiers, de tests et de documents peut augmenter rapidement. Mais l’augmentation de ces métriques ne signifie pas que le produit s’améliore réellement. Des fonctionnalités sont ajoutées, mais l’UX peut rester maladroite ; les tests passent, mais le parcours réel à l’écran peut rester instable. Au début, l’auteur a tenté de voir cela uniquement comme un problème de qualité et de structure du code. Mais il constate que même améliorer la structure du code n’améliore pas automatiquement l’expérience produit. En fin de compte, la production de code et l’amélioration du produit sont deux problèmes distincts, et un jugement séparé sur la qualité produit est nécessaire. 8. Le frontend est un domaine où l’IA est particulièrement susceptible de déraper L’IA peut créer rapidement des premières UI convaincantes, comme des dashboards, des landing pages ou des interfaces d’administration. Mais un frontend de niveau produit exige des critères complexes : design system, gestion d’état, accessibilité, navigation au clavier, états d’exception, parcours utilisateur, etc. Beaucoup d’exigences frontend s’expriment dans un langage flou, comme « naturellement », « moins maladroit » ou « donner l’impression que c’est sélectionné ». Lorsqu’elle transforme ces exigences ambiguës en code, l’IA produit facilement des résultats divergents. Pour bien utiliser l’IA en frontend, il faut donc des critères et un jugement permettant de verrouiller les parties réussies et de ne faire retravailler que les parties insuffisantes. 9. Les bons résultats n’apparaissent pas d’un seul coup, mais par un processus de convergence L’auteur change de perception après avoir vu un prototype très abouti créé par un planificateur avec l’IA. Ce résultat n’était pas le fruit d’un prompt exceptionnel, mais d’ajustements répétés « jusqu’à ce que ça marche ». Ce cas montre que l’essentiel dans l’usage de l’IA n’est pas la génération automatique simple, mais un processus de convergence consistant à observer continuellement ce qui manque et à reformuler les demandes. Les personnes qui produisent de bons résultats savent juger ce qui manque dans les livrables de l’IA et les ajuster avec persévérance jusqu’au niveau souhaité. Même à l’ère de l’IA, les critères, le sens du détail et la validation continue par les humains font la différence dans les résultats. 10. Les développeurs ont pour rôle de transformer des résultats prometteurs en produits Les résultats produits par l’IA peuvent sembler bons en apparence, tout en ayant une structure de code interne fragile. Des problèmes peuvent apparaître : gestion d’état instable, responsabilités de composants ambiguës ou tests qui ne garantissent pas le parcours réel. Le rôle des développeurs n’est pas de dévaluer ou de jeter systématiquement ces résultats. Mais il ne faut pas non plus les mettre en produit tels quels. Les développeurs doivent organiser la structure, signaler les risques, créer des unités testables et conserver le contexte afin que des résultats prometteurs puissent aller plus loin. Autrement dit, leur rôle s’étend : ils ne sont plus seulement « ceux qui construisent tout seuls jusqu’au bout », mais ceux qui transforment les résultats créés par l’IA et les humains en produits durables. 11. Les rôles du développement à l’ère de l’IA ne convergent pas vers un modèle unique Quand la barrière du codage s’abaisse, les profils qui participent au développement se diversifient également. Les planificateurs, designers, PM et responsables métier peuvent eux aussi créer des prototypes fonctionnels ou des outils internes avec l’IA. Cela ne signifie pas que les développeurs ne sont plus nécessaires, mais que les rôles liés au développement deviennent plus spécialisés. L’auteur compare cela à l’écosystème YouTube. De même que YouTube n’a pas supprimé les professionnels de la vidéo mais a diversifié les rôles — intervenants, monteurs, concepteurs, gestionnaires de chaînes, créateurs de plateformes —, l’IA peut diversifier les rôles du développement. À l’avenir, il est très probable que coexistent des personnes qui construisent des systèmes profonds, d’autres qui transforment des prototypes en produits, d’autres qui créent des couches permettant à l’IA de bien travailler, et d’autres encore qui résolvent directement des problèmes. Conclusion Les développeurs doivent concevoir le développement après le codage La conclusion de l’article n’est pas une opposition binaire entre « faut-il continuer à coder ? » et « faut-il lâcher prise ? ». Puisque l’IA est devenue capable d’exécuter du codage, les développeurs doivent apprendre par l’expérience ce qu’ils doivent lui confier et ce qu’ils doivent juger eux-mêmes. Les compétences suivantes deviennent particulièrement importantes. La capacité à définir des problèmes plus vastes La capacité à transformer des procédures répétitives en skills et workflows La capacité à structurer les exigences, documents, tests et issues La capacité à relire les livrables de l’IA et à redemander ce qui manque La capacité à transformer des résultats bruts en produits durables La capacité à connecter à l’IA des outils et des flux de travail au-delà du code Message clé L’IA n’est pas aussi parfaite que les développeurs l’espèrent, mais elle peut accomplir beaucoup plus de choses qu’on ne l’imagine. Avant de conclure qu’elle ne peut pas faire quelque chose, il faut expérimenter jusqu’où on peut réellement la pousser. À l’inverse, ce n’est pas parce que l’IA facilite une tâche qu’il faut faire confiance telle quelle au résultat. Les développeurs doivent juger les résultats produits par l’IA, les faire converger, préserver le contexte et les faire déboucher sur un produit. En fin de compte, à l’ère de l’IA, le développeur devient moins une personne qui écrit beaucoup de code directement qu’une personne qui conçoit les problèmes, les procédures, les critères et le contexte afin que les livrables produits par l’IA et les humains conduisent à de meilleurs résultats.

(velog.io/@teo)

6 points par baeba 5 시간 전 | Aucun commentaire pour le moment. | Partager sur WhatsApp

Résumé

Thèse principale
- Alors que l’IA atteint un niveau où elle peut écrire, modifier et tester directement du code, le rôle des développeurs se déplace du simple codage vers la définition des problèmes, la conception des tâches, la validation, la gestion du contexte et l’accompagnement de la mise en produit.
Causes structurelles
- L’IA a fortement accéléré la production de code, mais du code ne devient pas automatiquement un bon produit.
- Les domaines hors codage, comme les exigences, la documentation, les tests, la structuration, les choix d’UX et la maintenabilité, gagnent encore en importance.
Principaux exemples
- Une expérience consistant à permettre à l’IA d’exécuter jusqu’aux tests navigateur via Playwright.
- Une expérience de spécification de tâches répétitives sous forme de commandes, de skills et de workflows.
- Le cas d’un prototype frontend créé par IA, excellent en apparence mais fragile dans sa structure interne.
Pistes de solution
- Ne pas confier seulement le code à l’IA, mais concevoir avec elle les procédures et les critères de tout le processus de développement.
- Les développeurs doivent relire les livrables de l’IA, conserver le contexte et organiser la structure pour qu’ils puissent déboucher sur des produits durables.

Introduction

Le tournant de l’ère du codage par IA

L’article part de la question suivante : « Que doivent faire les développeurs à une époque où les humains ne codent plus directement ? »
L’auteur estimait auparavant que, puisque l’IA produisait des hallucinations et des erreurs, la décision finale devait revenir aux humains.
Mais avec les progrès récents des modèles d’IA, il estime que l’IA a atteint un niveau où elle peut comprendre les issues, explorer les fichiers, modifier le code et même faire passer les tests.
Ce changement amène les développeurs à aller au-delà d’un simple usage de l’IA comme outil d’assistance, et à réfléchir à la manière de lui faire exécuter le processus de développement lui-même.

Problématique centrale

L’IA est devenue capable de bien écrire du code, mais cela ne signifie pas que le rôle des développeurs disparaît.
Au contraire, plus le codage s’automatise, plus les autres composantes du développement deviennent visibles.
La clarification des exigences, l’enregistrement des décisions, la conception des tests, la gestion de la structure du code et la revue de l’expérience produit émergent comme des tâches centrales des développeurs.

Développement

1. L’IA est passée d’outil d’écriture de code à acteur d’exécution des tâches

L’auteur considère que l’IA a dépassé le stade de la simple génération de fragments de code et peut désormais traiter de véritables flux de travail de développement.
Auparavant, les humains devaient surveiller et corriger en permanence les résultats de l’IA ; désormais, il devient possible de lui confier des tâches puis d’en vérifier les résultats.
L’amélioration des performances sur des benchmarks comme SWE Bench est mentionnée comme un indicateur de cette évolution.
Le changement clé n’est plus de se demander « l’IA peut-elle écrire du code ? », mais « jusqu’où peut-on confier du travail à l’IA ? ».

2. Quand l’IA échoue, le problème n’est pas seulement un « manque de capacité »

L’IA ne réussit toujours pas à tous les coups.
Il arrive que des erreurs se répètent, ou que l’IA affirme avoir corrigé un problème alors que celui-ci subsiste à l’écran.
Au début, l’auteur réagissait en copiant les erreurs pour les transmettre à l’IA.
Puis, en utilisant Playwright pour faire ouvrir le navigateur et exécuter les tests directement par l’IA, il a compris que les procédures de validation jusque-là effectuées par des humains pouvaient elles aussi être confiées à l’IA.
Ce cas montre qu’une partie de ce que l’on prenait pour des limites de l’IA provenait en réalité du fait que l’utilisateur ne lui avait pas donné les bonnes instructions.

3. Une approche AI Native consiste à déléguer l’ensemble de la procédure

L’auteur quitte la perspective où l’IA n’est qu’un simple outil d’assistance et s’oriente vers une approche où l’IA exécute l’ensemble des procédures qu’il effectuait lui-même.
Il transforme les tâches répétitives en commandes, skills et workflows, et tente de formaliser son savoir tacite.
Il crée par exemple des flux de commandes comme /plan, /prd, /debug, /refactor, /verify et /retrospect.
Le point important n’est pas simplement de dire à l’IA « écris le code », mais de définir des règles indiquant quand poser des questions, quand s’arrêter et quand valider.
Cela conduit les développeurs à transformer leurs méthodes de travail et leurs critères de décision en structures réutilisables par l’IA.

4. Les savoir-faire individuels sont rapidement absorbés par les fonctionnalités des outils

Les commandes et workflows que l’auteur créait lui-même finissent, avec le temps, par apparaître sous forme de fonctionnalités et de concepts officiels comme les skills, la memory, les hooks et l’orchestration.
Plus une méthode d’utilisation de l’IA découverte par un individu est efficace, plus elle est rapidement absorbée par des fonctionnalités produit ou des méthodes communes.
Il est donc difficile de créer une différenciation durable avec un simple prompt ou une astuce spécifique pour mieux utiliser l’IA.
Ce qui compte, plus que la méthode elle-même, c’est de l’avoir appliquée à de vrais problèmes, d’avoir vu jusqu’où elle permettait d’aller et quelles limites elle révélait.

5. L’IA augmente la taille des problèmes que les développeurs peuvent traiter

L’IA permet à l’auteur d’expérimenter concrètement de grandes idées qu’il n’aurait pas pu tenter auparavant en raison du coût et du temps nécessaires.
Il crée rapidement, par exemple, des outils permettant de déployer code et documents comme sur un canvas, des visualiseurs MD, des outils d’analyse de code et des assistants de développement.
L’essentiel n’est pas que l’IA fournisse immédiatement un produit fini, mais qu’elle abaisse la barrière au démarrage.
Les développeurs passent ainsi de « pourrais-je créer cela ? » à « jusqu’où puis-je déjà aller en l’essayant ? ».

6. Traiter de grands problèmes fait apparaître les tâches de développement hors codage

Lorsque le volume de code produit par l’IA augmente, il devient difficile pour les développeurs de lire tout le code eux-mêmes et d’en garder le contexte en tête.
Quand on code directement, le contexte, les décisions et la compréhension structurelle s’accumulent naturellement ; lorsqu’on confie le codage à l’IA, ils ne sont pas automatiquement conservés.
Les documents, les tests, les issues, les rapports de travail et l’enregistrement des raisons des changements deviennent donc importants.
Il ne s’agit pas de tâches de gestion, mais de mécanismes essentiels pour préserver le contexte de développement à l’ère de l’IA.
L’auteur souligne que la capacité à préserver le contexte et le jugement devient aussi importante que la capacité à coder.

7. Plus de commits et de tests ne signifie pas forcément un meilleur produit

Avec l’IA, le nombre de commits, de fichiers, de tests et de documents peut augmenter rapidement.
Mais l’augmentation de ces métriques ne signifie pas que le produit s’améliore réellement.
Des fonctionnalités sont ajoutées, mais l’UX peut rester maladroite ; les tests passent, mais le parcours réel à l’écran peut rester instable.
Au début, l’auteur a tenté de voir cela uniquement comme un problème de qualité et de structure du code.
Mais il constate que même améliorer la structure du code n’améliore pas automatiquement l’expérience produit.
En fin de compte, la production de code et l’amélioration du produit sont deux problèmes distincts, et un jugement séparé sur la qualité produit est nécessaire.

8. Le frontend est un domaine où l’IA est particulièrement susceptible de déraper

L’IA peut créer rapidement des premières UI convaincantes, comme des dashboards, des landing pages ou des interfaces d’administration.
Mais un frontend de niveau produit exige des critères complexes : design system, gestion d’état, accessibilité, navigation au clavier, états d’exception, parcours utilisateur, etc.
Beaucoup d’exigences frontend s’expriment dans un langage flou, comme « naturellement », « moins maladroit » ou « donner l’impression que c’est sélectionné ».
Lorsqu’elle transforme ces exigences ambiguës en code, l’IA produit facilement des résultats divergents.
Pour bien utiliser l’IA en frontend, il faut donc des critères et un jugement permettant de verrouiller les parties réussies et de ne faire retravailler que les parties insuffisantes.

9. Les bons résultats n’apparaissent pas d’un seul coup, mais par un processus de convergence

L’auteur change de perception après avoir vu un prototype très abouti créé par un planificateur avec l’IA.
Ce résultat n’était pas le fruit d’un prompt exceptionnel, mais d’ajustements répétés « jusqu’à ce que ça marche ».
Ce cas montre que l’essentiel dans l’usage de l’IA n’est pas la génération automatique simple, mais un processus de convergence consistant à observer continuellement ce qui manque et à reformuler les demandes.
Les personnes qui produisent de bons résultats savent juger ce qui manque dans les livrables de l’IA et les ajuster avec persévérance jusqu’au niveau souhaité.
Même à l’ère de l’IA, les critères, le sens du détail et la validation continue par les humains font la différence dans les résultats.

10. Les développeurs ont pour rôle de transformer des résultats prometteurs en produits

Les résultats produits par l’IA peuvent sembler bons en apparence, tout en ayant une structure de code interne fragile.
Des problèmes peuvent apparaître : gestion d’état instable, responsabilités de composants ambiguës ou tests qui ne garantissent pas le parcours réel.
Le rôle des développeurs n’est pas de dévaluer ou de jeter systématiquement ces résultats.
Mais il ne faut pas non plus les mettre en produit tels quels.
Les développeurs doivent organiser la structure, signaler les risques, créer des unités testables et conserver le contexte afin que des résultats prometteurs puissent aller plus loin.
Autrement dit, leur rôle s’étend : ils ne sont plus seulement « ceux qui construisent tout seuls jusqu’au bout », mais ceux qui transforment les résultats créés par l’IA et les humains en produits durables.

11. Les rôles du développement à l’ère de l’IA ne convergent pas vers un modèle unique

Quand la barrière du codage s’abaisse, les profils qui participent au développement se diversifient également.
Les planificateurs, designers, PM et responsables métier peuvent eux aussi créer des prototypes fonctionnels ou des outils internes avec l’IA.
Cela ne signifie pas que les développeurs ne sont plus nécessaires, mais que les rôles liés au développement deviennent plus spécialisés.
L’auteur compare cela à l’écosystème YouTube.
De même que YouTube n’a pas supprimé les professionnels de la vidéo mais a diversifié les rôles — intervenants, monteurs, concepteurs, gestionnaires de chaînes, créateurs de plateformes —, l’IA peut diversifier les rôles du développement.
À l’avenir, il est très probable que coexistent des personnes qui construisent des systèmes profonds, d’autres qui transforment des prototypes en produits, d’autres qui créent des couches permettant à l’IA de bien travailler, et d’autres encore qui résolvent directement des problèmes.

Conclusion

Les développeurs doivent concevoir le développement après le codage

La conclusion de l’article n’est pas une opposition binaire entre « faut-il continuer à coder ? » et « faut-il lâcher prise ? ».
Puisque l’IA est devenue capable d’exécuter du codage, les développeurs doivent apprendre par l’expérience ce qu’ils doivent lui confier et ce qu’ils doivent juger eux-mêmes.
Les compétences suivantes deviennent particulièrement importantes.
- La capacité à définir des problèmes plus vastes
- La capacité à transformer des procédures répétitives en skills et workflows
- La capacité à structurer les exigences, documents, tests et issues
- La capacité à relire les livrables de l’IA et à redemander ce qui manque
- La capacité à transformer des résultats bruts en produits durables
- La capacité à connecter à l’IA des outils et des flux de travail au-delà du code

Message clé

L’IA n’est pas aussi parfaite que les développeurs l’espèrent, mais elle peut accomplir beaucoup plus de choses qu’on ne l’imagine.
Avant de conclure qu’elle ne peut pas faire quelque chose, il faut expérimenter jusqu’où on peut réellement la pousser.
À l’inverse, ce n’est pas parce que l’IA facilite une tâche qu’il faut faire confiance telle quelle au résultat.
Les développeurs doivent juger les résultats produits par l’IA, les faire converger, préserver le contexte et les faire déboucher sur un produit.
En fin de compte, à l’ère de l’IA, le développeur devient moins une personne qui écrit beaucoup de code directement qu’une personne qui conçoit les problèmes, les procédures, les critères et le contexte afin que les livrables produits par l’IA et les humains conduisent à de meilleurs résultats.