Un auteur de Habr parodie Onéguine : c'est l'humain qui répond des erreurs de l'agent

Quatre vers de parodie de la « Lettre de Tatiana à Onéguine » et une déclaration de méthode. Ainsi commence l'article d'auteur publié sur Habr, « La poésie du développement agentique, ou comment écrire du code aujourd'hui ». Son auteur refuse de livrer un énième lot de recettes et propose de monter d'un niveau d'abstraction : comprendre la problématique, les valeurs et le sens, et laisser les détails pour plus tard. L'annonce disponible ne contient que l'introduction ; nous analysons donc le cadre annoncé, pas l'argumentation.

Ce qui est exactement annoncé

Dans le poème, l'ingénieure Tatiana écrit à Eugène, vibe coder. L'agent, lui dit-elle, peut tout écrire. Mais c'est Eugène lui-même qui devra, bon gré mal gré, répondre des erreurs. La blague fonctionne parce qu'elle décrit une asymétrie bien réelle. Générer du code ne coûte presque plus rien, mais la responsabilité qui y est attachée n'a pas changé et incombe toujours à l'humain.

Caractéristiques du texte :

• Format : article d'auteur, rubrique AI de Habr
• Date de publication : 10 octobre 2026
• Image centrale : l'ingénieure Tatiana et le vibe coder Eugène
• Thèse principale : la responsabilité du résultat ne passe pas à l'agent
• Méthode : d'abord la problématique, les valeurs et le sens, ensuite les détails
• Ce que l'annonce ne contient pas : outils, mesures, pratiques concrètes

Pourquoi la thèse touche un point sensible

Le terme « vibe coding » a été proposé par Andrej Karpathy début 2025. Il décrivait un style où le développeur accepte les modifications de l'agent sans les relire. Pour un prototype ou un projet du dimanche, c'est acceptable. En production, cette approche revient à injecter dans le système du code que personne ne comprend.

L'agent écrit plus vite que l'humain ne lit. Le goulot d'étranglement se déplace donc de l'écriture vers la vérification. C'est une logique partagée par toute l'industrie, pas une conclusion de l'auteur de l'article, mais la blague sur Tatiana et Eugène la résume bien : celui qui a validé le diff en répond lors de l'incident.

Forces et faiblesses du cadre choisi

Monter en abstraction est une démarche raisonnable. Les recettes pour agents vieillissent en quelques mois : les modèles, les interfaces et les limites de contexte changent. Les questions de savoir qui est propriétaire du résultat, ce qu'on considère comme du code terminé et quel niveau de risque est acceptable restent valables nettement plus longtemps.

Il y a aussi un risque. Un texte sur le sens se transforme facilement en essai dont on ne peut tirer aucune action. Seule la version complète permettra de juger si l'auteur y a échappé. L'annonce ne comporte ni exemples, ni comparaison d'approches.

Que faire côté équipe

Ce ne sont pas les conseils de l'auteur, mais nos conclusions tirées de la thèse annoncée. Elles sont applicables dès maintenant :

• Désignez un responsable pour chaque modification faite par un agent. Il doit s'agir d'une personne précise, pas de « l'équipe ».
• Adoptez une règle : je ne merge pas ce que je ne peux pas expliquer avec mes propres mots.
• Rédigez les tests et les critères d'acceptation avant de lancer l'agent. La vérification s'appuie alors sur une spécification, et non sur l'impression que le code a l'air plausible.
• Conservez la tâche et les prompts clés à côté du commit. Six mois plus tard, cela aidera à comprendre pourquoi le code a pris cette forme.
• Séparez les modes de travail. Un prototype peut se faire « au feeling » ; le code de production doit être relu en review.

Le texte complet sur Habr mérite d'être lu pour voir ce que l'auteur fait de ces valeurs et de ce sens. Si des pratiques concrètes s'y cachent, ce sera un article utile. Sinon, il restera une jolie parodie assortie d'une observation juste.