Que montrer quand l'agent écrit du code en cinq minutes

Quand un agent écrit en cinq minutes l'architecture, le framework, les fonctionnalités de base et la moitié du code opérationnel, que montrer dans le portfolio d'un développeur ? La base de code n'est plus un signal de maîtrise — n'importe qui ayant accès au même agent peut l'écrire.

Cette question reprend un principe du livre d'Austin Kleon « Show Your Work! » : ne pas attendre la fin d'un projet, mais montrer le processus par petites étapes, en enseignant aux autres ce que l'on sait. Mais en 2026, cela demande une révision : il faut montrer non pas des artefacts, mais des jugements.

Six choses à montrer au lieu du code

Ce qui révèle votre travail quand le code est déjà écrit par l'agent :

• Les décisions et les options rejetées. Elles révèlent un jugement que l'agent n'a pas sur votre projet. Quand un catalogue de serveurs MCP a retiré deux points pour des noms de fonctions sans points (comme `stories.search`), c'était une décision délibérée : les grands fournisseurs de modèles ne tolèrent pas les points dans les noms, et des noms conformes au catalogue auraient cassé les clients pour lesquels le serveur existe.

• Les échecs et la méthode de diagnostic. Google a commencé à qualifier des pages de « soft 404 », alors qu'elles s'ouvraient normalement dans le navigateur. La cause : une seule ligne dans robots.txt bloquait l'API de récupération du contenu. Google effectue le rendu comme un navigateur, n'a pas pu récupérer les données et a vu un écran d'erreur.

• Comment vous avez vérifié le travail de l'agent. La compétence la plus importante aujourd'hui, et invisible dans le code. Trois exemples en une semaine : un test du serveur vérifiait le mauvais code d'erreur et passait depuis plusieurs jours, jusqu'à ce qu'un vrai client via un outil tiers plante avec une exception ; un bloc de statistiques était vide en production à cause d'une politique de sécurité du CDN que le navigateur de test n'appliquait pas ; Google a trouvé des pages inexistantes se terminant par `.

mdread-only` — le lien vers le texte source était collé à l'annotation, le navigateur affichait un espace que le code source ne contenait pas, et Google a fusionné les deux en une seule adresse.

• Les instructions données à l'agent après une erreur. Les règles dans la configuration, les compétences réutilisables. Après le bug lié à la politique de sécurité, le déploiement refuse désormais de publier des pages contenant des scripts intégrés. Après l'écart entre le registre du serveur et son fonctionnement réel, le déploiement échoue si la surface publique a changé sans nouvelle version.

• Les chiffres avant/après. Le résultat se montre facilement, même quand le système lui-même ne peut pas l'être. « Deux jours après la correction, Google a cessé de qualifier les pages de soft 404 » ou « le contrôle attrape désormais ce problème avant la mise en production » en dit plus qu'un diff.

• Ce que vous feriez différemment. Une analyse honnête inspire plus confiance qu'un récit de succès, et s'avère plus utile pour ceux qui font un travail similaire.

Comment ça marche : un scénius plutôt qu'un solitaire

Quand vous montrez des décisions et des erreurs plutôt que du code, des personnes aux expériences différentes réagissent. Deux échanges en commentaires sur dev.to à propos d'un serveur MCP se sont transformés en fonctionnalités produit : une vérification de version et une suite de tests via un vrai client.

Un de ces échanges est parvenu jusqu'à Sidney Bissoli, auteur de sept serveurs MCP pour les données ouvertes brésiliennes. Il en a tiré un outil à part, l'a fait tourner sur ses 142 versions de serveurs, a trouvé deux versions qui ne se lançaient pas du tout, et a écrit un article concluant qu'« un seul fil de commentaires a changé la manière dont huit serveurs sont publiés ». Austin Kleon appelle cela le « scénius » — le bon travail naît dans un groupe qui se montre mutuellement ce qu'il fait, pas chez un individu isolé.

En entreprise : le mécanisme sans les noms

Sur worklore.dev, on publie de courtes histoires : ce qui a été tenté, ce qui a cassé, ce qui a fonctionné. Quand l'agent de quelqu'un reproduit une histoire, cela est pris en compte sur la page. Le contenu qui ne peut pas être généralisé pour le public vaut quand même la peine d'être noté pour soi-même — votre propre agent répétera la même erreur dans quelques mois, quand les détails seront oubliés.

Même dans des projets fermés, la majeure partie peut être montrée en conservant le mécanisme et en retirant les noms. « Service interne », « étape de paiement », « notre CDN » — la leçon ne dépend presque jamais de la marque. Montrez le raisonnement, pas l'artefact : pourquoi ce choix, comment vous l'avez vérifié, ce que vous changeriez. Demandez l'autorisation une seule fois — la plupart des responsables ne s'opposent pas à une leçon anonymisée. Le format court convient : un problème, une correction, 300 mots. Un schéma pratique : contexte → où l'agent était sûr de lui et s'est trompé → diagnostic → ce qui a été changé pour que cela ne se reproduise pas.