L’agentic engineering est du travail client. Le vibe coding est une expérience.

Andrej Karpathy a forgé le terme le 2 févr. 2025 dans un post sur X : “There's a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.” Une nouvelle façon de coder où l’on s’abandonne aux vibes et où l’on oublie que le code existe. Dans le même post, il la jugeait “not too bad for throwaway weekend projects”, pas si mal pour des projets jetables du week-end.

Quelques semaines plus tard, Simon Willison a précisé le terme : le vibe coding, c’est “building software with an LLM without reviewing the code it writes”, construire un logiciel avec un LLM sans relire le code qu’il écrit. Si vous relisez le code, le testez et pouvez l’expliquer à quelqu’un d’autre, c’est du développement logiciel.

C’est la définition utile. Le vibe coding n’est pas un jugement sur le code écrit par l’IA. Il décrit la décision de ne pas le regarder.

Un an plus tard, le 4 févr. 2026, Karpathy a dressé le bilan. Programmer avec des agents LLM devenait, écrivait-il, un mode de travail standard pour les professionnels, “except with more oversight and scrutiny”, avec davantage de supervision et d’examen. Le nom qu’il préférait : agentic engineering.

« Agentic », parce que “you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight” : 99 % du temps, vous n’écrivez pas le code vous-même, vous orchestrez les agents qui le font et vous les supervisez. « Engineering », parce que “there is an art & science and expertise to it”, un savoir-faire qui s’apprend.

En pratique, les agents écrivent le code, lancent les tests et proposent des modifications. Vous fixez l’objectif, découpez le travail en morceaux qu’un agent peut terminer, lisez le diff, décidez de ce qui part en production et en répondez.

Un client n’achète pas du code. Il achète l’assurance que cela fonctionne, que c’est sûr et que quelqu’un en répond. Rien de cela ne passe à l’agent.

La qualité vient de la relecture, pas du modèle. Un agent qui écrit cent lignes en une minute écrit aussi cent lignes que quelqu’un doit vérifier.

La responsabilité reste à celui qui signe la facture. « C’est l’agent » n’est pas une réponse qu’un client accepte.

La traçabilité est la nouveauté. Quand un agent a tourné une heure sur le projet d’un client, le client devrait pouvoir voir ce qu’il a fait, pas seulement que cela a été facturé.

Les heures étaient un indicateur honnête tant que des personnes tapaient le code. Avec les agents, temps de travail et effort ne coïncident plus.

Cinq minutes de prompt lancent une heure de travail d’agent, suivie de quinze minutes de relecture. Plusieurs projets avancent en même temps. Et qui facture à l’heure gagne moins précisément quand il livre davantage en moins de temps.

L’effort ne devient pas pour autant secondaire. Moins vous facturez à l’heure, plus vous devez savoir ce qu’un projet a réellement demandé : au forfait, pour voir s’il a été rentable ; en régie, pour répercuter l’effort intégralement et d’une façon que votre client peut suivre.

• L’effort : votre temps de travail, le temps d’exécution actif des agents et les tokens utilisés, par projet.
• L’avancement : de quoi traitait chaque session et quels commits en sont sortis.
• La valeur : ce que valait le projet au regard de ce qu’il a demandé, facturé en régie ou au forfait.

Vous pouvez vendre du vibe coding pour ce qu’il est : un prototype, une maquette, une expérience dont personne ne maintiendra le code. Dites-le dans le devis.

Un logiciel qu’un client va exploiter, faire évoluer et dont il dépendra est un autre produit. C’est de l’agentic engineering, et il se facture et se documente comme de l’ingénierie.