Du Vibe Coding à l’Agent Engineering : Ce qui a vraiment changé
En février 2025, Andrej Karpathy a publié un tweet qui a défini une époque : “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.”
Treize mois plus tard, dans le podcast No Priors, il a mis lui-même son terme à la retraite.
“I went from 80/20 of writing code myself versus delegating to agents to like 2/98. I don’t think I’ve typed a line of code since December.”
L’homme qui nous a donné le « vibe coding » le qualifie désormais de dépassé. Son nouveau terme : agentic engineering. Non pas parce que l’IA serait devenue moins performante pour générer du code — mais parce que générer du code n’a jamais été la partie difficile.
Ce que Karpathy a vraiment dit
L’interview No Priors mérite d’être visionnée en intégralité, mais trois évolutions se distinguent :
1. Le ratio s’est inversé. Karpathy est passé d’écrire 80 % de son code à en écrire 2 %. Les agents s’occupent du reste. Le goulot d’étranglement s’est déplacé de la vitesse de frappe vers la compétence d’orchestration — la capacité à diriger plusieurs agents travaillant en parallèle.
2. « Le code n’est même plus le bon verbe. » Le développement logiciel est devenu de l’orchestration de macro-actions. On n’écrit plus de fonctions ; on délègue des fonctionnalités. On ne débogue plus ligne par ligne ; on révise au niveau architectural. Peter Steinberger gère des dizaines d’agents simultanément, chacun sur des tâches de 20 minutes réparties sur plusieurs dépôts.
3. AutoResearch retire totalement les humains de la boucle. Karpathy a construit une boucle de recherche autonome pour nanoGPT qui tourne de nuit en optimisant les hyperparamètres. Malgré ses années d’ajustement manuel, l’agent a trouvé des améliorations qu’il avait manquées — un weight decay oublié sur les value embeddings, des Adam betas insuffisamment calibrés. Sa conclusion : “To get the most out of the tools, you have to remove yourself as the bottleneck.”
Le fil conducteur : la valeur s’est déplacée de l’exécution au jugement. Le vibe coding était une question d’exécution — prompter, générer, déployer. L’agentic engineering est une question de jugement — architecture, vérification, orchestration.
Le manuel d’ingénierie pour la suite
La même semaine, Tw93 — créateur de Pake, Mole et prolifique ingénieur open source — a publié “You Don’t Know AI Agents,” un guide technique approfondi couvrant ce qu’il faut vraiment pour rendre les agents fiables en production. Là où Karpathy fournit la vision, Tw93 fournit le manuel d’ingénierie.
Sa thèse centrale : les harnesses comptent plus que les modèles.
“Using a more expensive model doesn’t always yield the massive improvements you’d expect. Instead, the quality of your harness and validation tests has a far greater impact on success rates.”
Ce n’est pas théorique. L’équipe d’ingénierie d’OpenAI l’a démontré : trois ingénieurs ont écrit un million de lignes de code en cinq mois — dix fois la vitesse traditionnelle. La clé n’était pas un meilleur modèle. C’étaient les bonnes décisions d’ingénierie concernant les contraintes, la validation et l’infrastructure des agents.
Cinq principes qui séparent le Vibe Coding de l’Agent Engineering
1. Context Engineering, pas Prompt Engineering
La complexité d’attention d’un Transformer est O(n²). Plus le contexte est long, plus les signaux cruciaux se diluent facilement. Le mode d’échec le plus courant n’est pas « le modèle ne peut pas le faire » — c’est le Context Rot : le contenu non pertinent s’accumule jusqu’à ce que la qualité décisionnelle de l’agent se dégrade visiblement.
La solution est une gestion du contexte en couches :
- Couche permanente : Identité, conventions, contraintes strictes. Courte, stable, toujours chargée.
- Couche à la demande : Compétences et connaissances du domaine. Les descripteurs restent résidents ; le contenu complet ne se charge qu’au déclenchement.
- Injection en temps d’exécution : Horodatages, préférences utilisateur, état dynamique. Ajouté à chaque tour.
- Couche mémoire : Expérience inter-sessions. Lue uniquement quand c’est pertinent, pas fourre-tout dans chaque prompt.
L’enseignement clé : ne mettez pas de logique déterministe dans le contexte. Tout ce qui peut s’exprimer comme règles de code, linters ou hooks doit être géré par des systèmes externes. Le modèle doit penser, pas lire des règlements.
2. Conception d’outils selon les principes ACI
La plupart des défaillances d’outils ne viennent pas du fait que le modèle choisit le mauvais outil — elles viennent du fait que l’outil a été conçu pour des ingénieurs, pas pour des agents. Le cadre Agent-Computer Interface (ACI) change la perspective de conception :
| Aspect | Mauvaise conception | Bonne conception |
|---|---|---|
| Granularité | Correspond aux endpoints API | Correspond aux objectifs de l’agent |
| Retourne | Données brutes complètes | Champs pertinents pour la décision suivante |
| Erreurs | Chaîne générique | Structurées avec suggestions de correction |
| Description | Ce que ça fait | Quand l’utiliser et quand NE PAS l’utiliser |
Un exemple concret : plutôt que de fournir get_post + update_content + update_title comme outils séparés, fournissez update_yuque_post qui exprime l’action complète en un seul appel. Les contre-exemples dans les descriptions d’outils font passer la précision de 53 % à 85 %.
Lors du débogage d’agents, vérifiez les définitions d’outils en premier. La plupart des erreurs de sélection d’outils proviennent de descriptions inexactes, pas des capacités insuffisantes du modèle.
3. La mémoire comme infrastructure, pas comme réflexion après coup
Les agents n’ont pas de continuité temporelle native. Quand une session se termine, le contexte disparaît. Quatre types de mémoire résolvent des problèmes différents :
- Mémoire de travail (fenêtre de contexte) : État actuel de la tâche. Gérée activement.
- Mémoire procédurale (compétences) : Comment faire les choses. Chargée à la demande.
- Mémoire épisodique (journaux de session) : Ce qui s’est passé. Persistée, consultable.
- Mémoire sémantique (MEMORY.md) : Faits stables. Injectée au démarrage.
Le choix de conception critique : la consolidation de la mémoire doit être réversible. Lors de la compaction de longues conversations, ne supprimez pas les messages bruts — archivez-les. Déplacez un pointeur, ne détruisez pas de données. Si la consolidation produit un mauvais résumé, l’agent peut toujours se rabattre sur l’historique brut.
4. Évaluation avant optimisation
L’évaluation des agents est fondamentalement plus difficile que les tests traditionnels. L’espace d’entrée est infini, les LLM sont sensibles à la formulation des prompts, et la même tâche peut produire des résultats différents d’une exécution à l’autre.
Deux métriques, deux objectifs :
- Pass@k : Au moins une exécution correcte sur k. Teste les limites de capacité. À utiliser en développement.
- Pass^k : Toutes les k exécutions correctes. Teste la fiabilité. À utiliser avant le déploiement.
L’anti-pattern le plus dangereux : ajuster l’agent quand l’évaluation est défaillante. Si votre notation est erronée, vous optimisez contre des signaux distordus. Quand les performances chutent, vérifiez d’abord l’infrastructure — limites de ressources causant des plantages, évaluateurs buggués, ou cas de test déconnectés de la réalité — avant de modifier l’agent.
5. La coordination multi-agents nécessite des protocoles
Faire tourner plusieurs agents n’est pas une question de parallélisme — c’est une question d’isolation et de coordination. Les sous-agents ne doivent renvoyer que des résumés ; leurs processus de recherche, d’essai-erreur et de débogage restent dans leur propre contexte. Le contexte de l’agent principal ne reçoit que des conclusions.
L’ordre compte : définissez d’abord les protocoles, établissez ensuite l’isolation, puis parlez de collaboration. Sans communication structurée (files de messages JSONL, graphes de tâches, isolation des espaces de travail), les erreurs s’amplifient entre les agents. L’agent A dérive, l’agent B renforce le biais, l’agent C l’empile, et tous trois convergent vers une mauvaise conclusion avec une grande confiance.
La progression en un tableau
| Phase | Rôle du développeur | Qualité du code | Vérification | Échelle |
|---|---|---|---|---|
| Codage manuel | Rédacteur | Haute (votre code) | Vous le testez | Une personne |
| Vibe coding | Prompteur | Variable | Vous le vérifiez | Un agent |
| Agentic coding | Architecte | Structurée | L’agent se teste lui-même | Plusieurs agents |
| Agent engineering | Orchestrateur | Harness-assistée | Évaluation automatisée | Équipes d’agents |
Chaque phase n’a pas remplacé la précédente — elle l’a englobée. Vous avez toujours besoin de discernement, de pensée architecturale, de compréhension du code. Mais la couche d’exécution s’éloigne de plus en plus de vos doigts.
Ce que ça signifie en pratique
Karpathy a construit un agent de domotique appelé “Dobby the House Elf” — trois prompts qui ont scanné son réseau local, fait de la rétro-ingénierie sur les API des appareils connectés, et remplacé six applications distinctes par des commandes WhatsApp. “Dobby, sleepy time” éteint tout.
Sa conclusion sur le logiciel : “These apps shouldn’t even exist. Shouldn’t it just be APIs and agents are the glue of intelligence that tool-calls all the parts?”
C’est la trajectoire. Le logiciel évolue des produits que vous opérez vers des agents qui opèrent les produits à votre place. L’interface s’effondre des interfaces graphiques vers le langage naturel. La complexité ne disparaît pas — elle se déplace dans le harness, les outils, l’évaluation, les systèmes de mémoire qui rendent les agents fiables.
Le vibe coding nous a mis à l’aise avec l’idée que l’IA écrit du code. L’agent engineering consiste à construire l’infrastructure qui rend le code écrit par l’IA digne de confiance, maintenable et autonome.
Les vibes étaient l’étape 1. L’ingénierie, c’est tout ce qui suit.
TeamDay fait tourner des agents IA autonomes dans le cloud — SEO, contenu, réseaux sociaux, analytique et plus encore. Les mêmes principes d’agent engineering que décrivent Karpathy et Tw93 propulsent notre force de travail IA. Commencez à construire votre équipe d’agents.