En février 2025, Andrej Karpathy a décrit le « vibe coding » comme la pratique consistant à décrire son intention en langage naturel, à accepter les modifications d'un LLM avec un minimum de vérification, et à laisser le code évoluer au-delà de sa compréhension habituelle. Cela offrait une vitesse impressionnante pour les projets personnels et les prototypes.
Un an plus tard, il a observé que les capacités des agents avaient évolué et a proposé l'« agentic engineering » comme nom préféré de la pratique évoluée consistant à orchestrer des agents tout en gardant une supervision humaine forte sur l'architecture et le processus. L'objectif, comme il l'a formulé, est de tirer parti des agents sans compromettre la qualité logicielle.
La distinction est importante. Le « vibe coding » fonctionne bien pour un utilisateur unique sur du travail personnel à faible enjeu, mais il accumule rapidement des dettes cachées, des failles de sécurité et des problèmes de maintenabilité dès que d'autres personnes dépendent du résultat. L'« agentic engineering » conserve la vitesse et l'avantage des agents modernes, mais ancre tout dans une structure claire, des artefacts traçables et une responsabilité humaine.
Le Workflow de l'Agentic Engineering
Commencez par une intention approximative et menez des conversations de conception avec l'IA tout en documentant la fonctionnalité dans des notes de réunion de conception, décrivant la fonctionnalité en ses parties composantes. Une fois la conception solide, capturez la vue d'ensemble et la carte des composants dans une hiérarchie de conception (c'est ce que les gens montrent lorsqu'ils présentent un « cerveau » Obsidian), une structure navigable qui donne à vous et à l'agent un accès facile au contexte environnant, aux décisions connexes et aux dépendances. C'est également là que résident les diagrammes de conception, tels que UML (langage de modélisation universel), les flux de code ou d'interaction utilisateur, ainsi que des liens vers les enregistrements de décisions architecturales (ADR) qui clarifient comment les composants se rapportent les uns aux autres.
Pour chaque module ou bloc de fonctionnalité le plus petit, créez un spec.md ciblé dans le LLD qui définit un comportement précis, des signatures de fonctions, des cas limites, des attentes de test et des points d'intégration. En utilisant l'ensemble de la structure comme contexte de conception, incitez l'IA à construire une hiérarchie de type ticket avec une traçabilité directe vers les pages wiki et les specs. Implémentez ticket par ticket, l'agent suivant le spec.md correspondant comme son contrat. Ensuite, exécutez des passerelles de vérification, déployez, observez et mettez à jour les artefacts vivants à mesure que les exigences évoluent.
Exemple Concret : Vérificateur de Sauvegarde Quotidienne
Considérez un petit outil CLI de qualité production qui vérifie les sauvegardes S3 quotidiennes et envoie des alertes Slack en cas d'échec.
Commencez par l'objectif approximatif : « J'ai besoin de quelque chose de fiable qui vérifie que mes sauvegardes sont saines chaque jour. » Puis menez des conversations architecturales avec l'IA pour faire émerger les exigences et les cas limites :
- Quels sont les modes de défaillance réalistes pour les sauvegardes S3 en pratique ?
- Que devrions-nous vérifier exactement (âge, nombre de fichiers, taille, taux de réussite), et quels seuils ont du sens ?
- Comment la configuration et les secrets doivent-ils être gérés entre le développement local et les rôles IAM de production ?
- Quelles commandes CLI et formats de sortie seraient utiles au quotidien ?
- Quelles exigences non fonctionnelles importent le plus pour un outil quotidien planifié ?
Ces conversations clarifient le périmètre et aident à décomposer l'outil en ses composants principaux : la récupération des métadonnées S3 avec logique de réessai, un moteur de règles de vérification, un système de notification, un chargeur de configuration, une interface CLI, une journalisation structurée et une gestion des erreurs.
Une fois la conception claire, vous documentez la vue d'ensemble et la carte des composants dans le wiki de la hiérarchie de conception, où chaque page est versionnée et liable.
Le wiki offre aux futurs lecteurs le contexte environnant qu'un document plat ne peut pas fournir. Dans le cadre du même travail de conception, vous créez un spec.md ciblé au niveau sous-LLD pour chaque module. Voici le contrat pour le récupérateur de métadonnées S3.
Ce spec.md est le contrat que vous remettez à l'agent, par exemple : « Implémentez exactement selon spec.md dans le répertoire s3_client/, suivez les normes du projet et incluez des tests complets. » Avec le wiki et les specs des modules en place, vous incitez ensuite l'IA à générer la hiérarchie de tickets directement à partir d'eux. Chaque élément remonte à une exigence fonctionnelle et à la spec qui définit son contrat.
L'implémentation procède alors ticket par ticket, chacun étant remis à l'agent avec son spec.md correspondant comme contrat. Voici ce que cela produit en pratique : une exécution planifiée qui détecte un ensemble de sauvegarde court et déclenche l'alerte.
L'exécution se termine avec un code non nul pour que le cron job le remarque, et déclenche l'alerte qui atterrit dans Slack.
L'alerte contient le contexte de règle dont un ingénieur d'astreinte a besoin pour agir : quelle vérification a échoué, ce qui a été trouvé, ce qui était attendu et quel ensemble de sauvegarde.
Avantages de Cette Approche Par Couches
- Les agents gèrent le volume d'implémentation tandis que les humains sont responsables de l'architecture et de la qualité à chaque couche.
- Le wiki fournit une découvrabilité et des décisions au niveau du projet, tandis que les fichiers spec.md fournissent des contrats précis au niveau des modules sans alourdir la conception de haut niveau.
- Les exigences et les décisions transitent directement des pages wiki et des specs vers les tickets et le code.
- Les modifications partent d'artefacts de conception vivants plutôt que de faire de la rétro-ingénierie de la base de code.
- Une séparation claire des préoccupations favorise le travail parallèle, l'intégration et les audits.
- Les professionnels en forme de T naviguent avec largeur et questionnent avec précision, et l'agent fournit la profondeur à la demande sans forcer personne à garder l'intégralité du système en tête.
Le « vibe coding » reste un excellent mode d'exploration et de prototypage personnel rapide. L'« agentic engineering » est la façon dont vous canalisez cette même puissance conversationnelle dans des systèmes que d'autres personnes peuvent approuver et maintenir.
Le Rôle du Professionnel en Forme de T
Ce workflow est particulièrement puissant pour les professionnels en forme de T : des ingénieurs qui maintiennent une large connaissance de l'espace applicatif avec la capacité d'aller en profondeur là où c'est nécessaire.
Parce que vous n'avez pas besoin de maintenir un modèle mental complet et à jour de la façon dont l'ensemble de l'application fonctionne à tout moment. L'agent peut porter cette profondeur et réexpliquer n'importe quelle partie à la demande, tant qu'il dispose du bon contexte issu du wiki, des fichiers spec.md et de l'historique des conversations.
Ce dont vous avez besoin, c'est la capacité de savoir quoi chercher et où chercher, plus la discipline de poser des questions précises jusqu'à ce que vous compreniez l'élément spécifique sur lequel vous travaillez. La partie large du T vous donne la carte du système ; l'agent IA soutient les compétences nécessaires pour creuser le module exact, le cas limite ou le point d'intégration qui compte en ce moment. L'agent fournit le détail exhaustif chaque fois que vous demandez.
Cela fait passer le rôle humain de « Je dois tout comprendre tout le temps » à « Je sais comment naviguer, questionner et valider à la bonne altitude. » C'est là la véritable compétence de l'agentic engineering.
