Que montrer quand un agent écrit le code en 5 minutes ? Les développeurs cherchent la réponse

Cinq minutes. C'est le temps dont l'agent de votre voisin a besoin, selon l'auteur de la tribune sur Habr, pour reproduire le code que vous avez écrit avec votre propre agent. Il en conclut que la méthode habituelle pour se faire connaître dans le métier, c'est-à-dire publier du code, fonctionne de moins en moins bien. Le texte ouvre sur une question à laquelle l'introduction publiée ne répond pas encore : que doit montrer un développeur en 2026 ?

L'idée de Kleon et trois conseils

Le point de départ est le court livre d'Austin Kleon, « Show Your Work ! » (« Покажи свою работу! »). Sa thèse centrale : ne pas attendre d'avoir un résultat fini, mais montrer le processus. Les petits pas, ce que l'on apprend, ce qui inspire, la façon dont on avance vers son but. Il faut partager un peu à la fois, chaque jour, enseigner ce que l'on sait et veiller à ne pas tomber dans le spam. La logique est simple : les gens vous trouvent grâce à ce que vous partagez, et certains d'entre eux se mettent à vous aider.

Chez les développeurs, cette philosophie s'applique généralement de trois façons :

• publier du code en open source ;
• tenir un journal public de ce qui a été fait dans la journée ;
• décrire comment on a réfléchi à un problème.

L'auteur note que même les partisans de la première option reconnaissent que le résultat est ennuyeux.

Où chaque option atteint ses limites

Le principal reproche vise le code, et il comporte deux volets. Le premier est juridique et pratique : si le code appartient à l'employeur, on n'a pas le droit de le partager. Pour la plupart des développeurs salariés, c'est l'essentiel du travail quotidien. Le second volet est économique. Si l'agent a de toute façon généré le code, celui-ci cesse d'être une preuve unique de compétence. N'importe qui obtiendra le même résultat en confiant une tâche similaire à un outil similaire.

C'est un déplacement de l'objet même de la démonstration. Autrefois, un dépôt GitHub constituait une preuve indirecte de la capacité d'un développeur à résoudre des problèmes : commits, architecture, style. Quand un agent s'intercale entre l'énoncé de la tâche et le code qui fonctionne, le dépôt permet plus difficilement de savoir où s'arrête l'apport humain. L'employeur ou le collègue voit l'artefact, mais pas les décisions qui y ont mené.

Le journal de la journée et la description du raisonnement sont plus proches de ce que propose Kleon, mais ils ne règlent pas non plus entièrement le problème. Sans résultat concret, ces notes deviennent facilement de l'autodescription plutôt que la démonstration d'une valeur.

Ce que cela implique en pratique

Dans la partie accessible du texte, l'auteur ne donne pas de réponse toute faite. On peut seulement avancer une direction, à partir de la formulation même du problème. Si la valeur se déplace du texte du programme vers les décisions qui l'entourent, il est logique de montrer précisément celles-ci :

• quelle tâche vous avez choisie et lesquelles vous avez écartées ;
• comment vous avez formulé l'énoncé et vérifié le résultat de l'agent ;
• quelles erreurs du modèle vous avez repérées et comment vous les avez corrigées ;
• ce que vous avez appris sur le processus, que l'on peut raconter sans divulguer de code d'entreprise.

Cet ensemble ne viole pas le NDA, car il n'exige pas de publier les sources. L'agent du voisin ne le reproduira pas : ce sont des notes sur le jugement, pas sur la syntaxe. Et il respecte le conseil initial de Kleon, qui est de partager le processus, pas seulement le résultat.

Pour ceux qui construisent aujourd'hui leur présence publique, la conclusion est pratique. Inutile d'attendre le projet de portfolio parfait. On peut commencer par de courtes notes sur des décisions concrètes, en y retirant tout ce qui appartient à l'entreprise. La réponse complète de l'auteur figurera dans l'article principal sur Habr, accessible par le lien de la publication d'origine. En attendant, la question elle-même est révélatrice : l'industrie commence à débattre sérieusement de ce qui atteste le professionnalisme quand le code peut être écrit par autre chose qu'un humain.