L'histoire du logiciel est une histoire où l'on confie du travail à la machine. Nous avons commencé par perforer des instructions sur des cartes, puis laissé les compilateurs transformer des langages lisibles en code machine, puis laissé les machines virtuelles oublier sur quel ordinateur physique nous nous trouvions, puis laissé le cloud oublier la machine elle-même. Chaque étape ressemblait, à l'époque, à un abandon de contrôle. Chacune était en réalité une montée d'un niveau — l'échange d'une couche de labeur contre une couche de levier. Le développement agentique est la prochaine étape de cette même longue lignée, et c'est une étape plus grande que la plupart des précédentes.
L'abstraction a toujours été le fil de l'histoire
Aucun des changements précédents n'a rendu les développeurs obsolètes ; ils ont changé ce à quoi un développeur consacrait sa journée. Le compilateur n'a pas mis fin à la programmation, il a mis fin à l'écriture manuelle d'assembleur. Le cloud n'a pas mis fin aux opérations, il a mis fin au montage de serveurs en baie. Chaque fois que la machine absorbait la couche du dessous, l'humain montait à la couche du dessus — de la gestion de la mémoire à la gestion de la logique, de la gestion des serveurs à la gestion des systèmes.
Le schéma est si constant qu'il en devient presque une loi : ce qui devient bon marché à automatiser cesse d'être là où se trouve la valeur, et la valeur se déplace vers ce qui est désormais le plus rare. Pendant longtemps, la ressource rare a été l'implémentation — transformer une intention en code qui fonctionne. C'est exactement la couche que les agents sont en train d'absorber aujourd'hui.
Un agent est un collègue, pas une saisie semi-automatique plus rapide
L'erreur tentante consiste à classer les agents de codage dans la catégorie « meilleure saisie semi-automatique ». Ce sont des choses d'une autre nature. La saisie semi-automatique termine votre phrase ; un agent prend un objectif et agit en conséquence — il décide, dans les limites que vous fixez, quoi changer et comment, puis le fait. C'est moins un clavier plus intelligent qu'un collègue qui se trouve vivre dans le dépôt de code : vous lui confiez une issue, il s'absente, et il revient avec une merge request.
C'est exactement la forme sous laquelle nous avons construit TaskGoblin. Ce n'est pas un panneau dans votre éditeur. C'est un coéquipier dans les outils que votre équipe utilise déjà — des issues assignées, des mentions dans des fils de discussion, des relectures de pull requests — qui effectue l'implémentation dans un sandbox et vous rend un travail à examiner. L'unité d'interaction n'est pas une frappe au clavier. C'est une tâche.
À quoi commence à ressembler la journée
Poussez cela d'un cran et la forme de la journée de travail change. Les mises à jour de dépendances que personne ne veut faire sont réalisées pendant la nuit. Le test instable est élagué avant le stand-up. Une fonctionnalité bien spécifiée arrive sous la forme d'une pull request en brouillon, avec l'échafaudage et les tests déjà en place, en attente de jugement plutôt que de frappe. Un product manager déplace un ticket, et le temps que quelqu'un y jette un œil, la première version du changement est déjà ouverte. Le tapis roulant du labeur — ce travail nécessaire et peu glamour qui remplit tant de la semaine d'un ingénieur — ralentit enfin.
Ce qui reste, c'est la part qui a toujours été le véritable travail : décider ce qui doit être construit, remarquer quand l'implémentation évidente est subtilement erronée, porter le goût et le contexte qu'aucune quantité de capacité brute ne fournit. L'ingénieur passe d'auteur à éditeur — de producteur de chaque ligne à celui qui dirige ce qui est produit et tranche sur ce qui est juste.
La question passe de « peut-on ? » à « devrait-on ? »
Lorsque l'implémentation devient bon marché et rapide, la contrainte déterminante cesse d'être de savoir si vous pouvez construire quelque chose, pour devenir de savoir si cela vaut la peine d'être construit. L'itération devient assez bon marché pour que les revues de conception deviennent exploratoires — essayer trois versions plutôt que débattre d'une seule. Une petite équipe peut produire l'équivalent d'une équipe bien plus grande, parce que le levier par personne a augmenté. Et l'avantage concurrentiel se déplace en conséquence : loin de qui peut exécuter, vers qui a le goût de savoir quoi exécuter, l'empathie de comprendre à qui cela s'adresse, et la clarté d'articuler le problème assez bien pour qu'un agent puisse s'y atteler.
C'est là le recadrage véritable sous tout ce bruit. « Nous ne faisons désormais que gérer des essaims de développeurs juniors » est la version anxieuse ; la version plus vraie est que le levier s'est déplacé, et que la compétence rare s'est déplacée avec lui — vers le haut, vers le jugement.
Où l'humain reste
Une version honnête de cet avenir ne prétend pas que l'humain disparaît. C'est l'inverse : à mesure que la machine absorbe l'implémentation, les décisions humaines deviennent plus déterminantes, pas moins, parce que chacune d'elles pilote désormais bien plus de production. C'est pourquoi TaskGoblin maintient délibérément une personne au niveau du merge — l'agent écrit le code et relit le changement, mais il n'approuve jamais et ne merge jamais. Le jugement sur ce qui est juste pour ce système, à cet instant, est précisément la couche qui ne s'automatise pas, et c'est la couche vers laquelle nous montons tous.
Le tapis roulant ralentit. Ce qui déterminera qui façonnera la prochaine ère du logiciel ne sera pas qui peut implémenter — la machine s'en empare, comme elle s'est emparée des couches en dessous. Ce sera l'imagination, le goût, et le jugement nécessaire pour orienter toute cette capacité vers les choses qui méritent vraiment d'être construites.
