Du code aux agents IA : le nouvel ingénieur AI-native

Le titre du poste dit toujours "ingénieur logiciel". Mais le métier lui-même ? Il change plus vite que la plupart des ingénieurs ne le réalisent.

Dans une récente intervention sur la chaîne EO, Mihail Eric — responsable IA dans une startup de San Francisco et enseignant à Stanford — a présenté une vision qui devrait faire réagir chaque développeur. L'ère de l'ingénieur qui se contente d'écrire du code touche à sa fin. L'ère de l'ingénieur qui gère des agents IA a commencé.

Ce changement n'est pas hypothétique. Il se produit dans les codebases en production en ce moment même. Et les ingénieurs qui s'adaptent définiront la prochaine décennie du logiciel.

L'ingénieur AI-native : une nouvelle espèce

Eric décrit une nouvelle génération qui entre sur le marché du travail : l'ingénieur AI-native. Ce ne sont pas des développeurs qui utilisent occasionnellement Copilot pour l'autocomplétion. Ce sont des ingénieurs qui pensent en flux de travail agentiques dès le premier jour.

Mais voici ce qui rend le point de vue d'Eric rafraîchissant — il ne dit pas que les compétences traditionnelles ne comptent plus. C'est le contraire. Les ingénieurs AI-native ont besoin d'une base solide en programmation, conception de systèmes et pensée algorithmique. Sans cela, vous ne pouvez pas évaluer ce qu'un agent produit. Vous ne pouvez pas déboguer ses échecs. Vous ne pouvez pas concevoir des systèmes dans lesquels les agents peuvent réellement naviguer.

La différence est que, par-dessus cette base, les ingénieurs AI-native maîtrisent un second langage : l'orchestration d'agents autonomes pour accomplir le travail qui nécessitait auparavant de taper chaque ligne à la main.

C'est la différence entre un musicien qui ne fait que jouer et un chef d'orchestre qui dirige l'ensemble. Il faut toujours comprendre la musique. Mais le résultat passe à une autre échelle.

Du codeur au manager : le changement de mentalité

Eric fait une comparaison provocante : gérer des agents IA ressemble beaucoup à gérer des stagiaires humains.

Vous ne donneriez pas toute votre codebase à un stagiaire le premier jour en disant "refactore le système d'authentification". Vous commenceriez petit. Vous lui donneriez une tâche délimitée. Vous examineriez son travail. Puis vous élargiriez progressivement son périmètre à mesure que la confiance se construit.

Le même principe s'applique aux agents. Eric recommande une approche de délégation itérative :

Maîtrisez d'abord les flux mono-agent. Faites fonctionner un agent de manière fiable sur une tâche bien délimitée avant d'ajouter de la complexité.
Établissez des limites claires. Définissez ce que l'agent peut et ne peut pas toucher. Limitez son accès à des fichiers, modules ou opérations spécifiques.
Ajoutez des agents progressivement. N'introduisez un deuxième ou troisième agent que pour des tâches isolées et parallèles, une fois le premier stabilisé.
Surveillez constamment. Sachez quand les agents sont bloqués. Sachez quand ils hallucinent. Sachez quand intervenir.

La compétence n°1 qui sépare les grands ingénieurs AI-native des autres ? Selon Eric, c'est le changement de contexte — la capacité à suivre ce que font plusieurs agents simultanément, repérer quand l'un déraille et corriger le cap en temps réel.

C'est du management. Pas de la gestion de personnes, mais de la gestion d'intelligence. Et cela nécessite une façon fondamentalement différente de concevoir votre journée de travail.

Construire des codebases adaptées aux agents

C'est là que l'intervention d'Eric devient profondément pratique. Les agents IA ne sont aussi performants que l'environnement dans lequel ils opèrent. Déposez un agent dans une codebase désordonnée et incohérente, et il va amplifier les erreurs à la vitesse de la machine.

La solution ? Construisez votre codebase comme si vous intégriez le stagiaire le plus littéral du monde.

Les tests sont des contrats

Les agents n'ont pas d'intuition. Ils ne peuvent pas regarder du code et penser "quelque chose ne va pas". Ils ont besoin de contrats explicites — et cela signifie des tests.

Votre suite de tests n'est plus seulement de l'assurance qualité. C'est la spécification qui dit aux agents si leur code est correct. Sans une couverture de tests complète, les agents naviguent à l'aveugle. Ils généreront du code qui a l'air correct, passe la vérification syntaxique, et casse silencieusement votre application.

Si vous voulez que les agents contribuent du code significatif, investissez d'abord dans les tests.

La cohérence avant la ruse

Si votre codebase a deux patterns différents pour la même opération — disons deux façons différentes de faire des appels API, ou deux conventions de gestion d'erreurs — un développeur humain sera perdu. Un agent IA sera encore plus perdu.

Eric souligne que les codebases doivent être robustes, étanches et auto-cohérentes :

Votre README doit correspondre au code réel. Si la documentation dit une chose et le code en fait une autre, l'agent en choisira une au hasard.
Utilisez des design patterns cohérents entre les modules. Une seule façon de gérer l'authentification. Une seule façon de structurer les routes API. Une seule convention pour les réponses d'erreur.
Gardez vos dépendances propres. Les packages conflictuels ou obsolètes créent une ambiguïté que les agents gèrent mal.

Le principe est simple : si ça perturberait un nouveau recruté, ça perturbera un agent. Sauf que l'agent ne demandera pas de clarification — il écrira du mauvais code avec assurance.

La documentation comme interface

Cela va au-delà des README. Chaque module, chaque API, chaque fichier de configuration fait partie de l'interface que les agents utilisent pour comprendre votre système. Pensez à la documentation non pas comme quelque chose que vous écrivez pour de futurs humains, mais comme quelque chose que vous écrivez pour les agents qui travaillent à vos côtés maintenant.

La valeur du goût

Eric trace une ligne entre un logiciel fonctionnel et un logiciel exceptionnel. Ce qui fait la différence ? Le goût du développeur.

Les agents IA peuvent générer du code fonctionnel. Ils peuvent échafauder des fonctionnalités, écrire des tests et connecter des API. Mais les derniers 10% — la finition, les cas limites, les détails UX qui font que les utilisateurs adorent un produit — cela vient encore du jugement humain.

Eric appelle cela le problème du "dernier kilomètre". Les agents vous amènent à 90% rapidement. Mais le développeur qui livre un excellent logiciel est celui qui prend ce résultat et l'affine avec goût : de meilleurs noms, des messages d'erreur plus clairs, des interactions plus fluides, des performances plus serrées.

Et il y a une méta-leçon ici aussi. Eric note que même les meilleurs labos IA comme Anthropic réécrivent et expérimentent constamment avec leurs propres outils. Rien n'est figé. Les meilleurs outils d'aujourd'hui seront remplacés dans six mois.

Les développeurs AI-native doivent adopter la même posture : bidouiller, tester, itérer. Ne vous attachez pas à un flux de travail. Ne supposez pas que votre configuration d'agent actuelle est optimale. Continuez à expérimenter. Les développeurs qui prospéreront ne sont pas ceux qui ont trouvé le bon outil — ce sont ceux qui ne cessent jamais de chercher.

Pourquoi les juniors ont un avantage

C'est peut-être l'insight le plus contre-intuitif de l'intervention d'Eric. Dans un marché de l'emploi brutal pour les ingénieurs débutants, les développeurs juniors ont en réalité un avantage caché dans l'ère AI-native.

Pourquoi ? Parce que les développeurs seniors avec 20 ans d'expérience sont souvent ancrés dans leurs habitudes. Ils ont développé des réflexes autour de flux de travail antérieurs aux agents IA. Leur demander de changer fondamentalement leur façon de travailler se heurte à une vraie résistance psychologique.

Les développeurs juniors, en revanche, sont des éponges. Ils ont :

Aucune habitude héritée à désapprendre
Une naïveté saine qui les rend prêts à essayer des approches que les seniors rejetteraient
Une agilité pour adopter rapidement de nouveaux outils et flux de travail
Un courage entrepreneurial pour s'attaquer à des problèmes difficiles sans trop réfléchir

Le terrain de jeu est en train d'être remis à zéro. L'expérience compte toujours — mais l'adaptabilité compte davantage. Un développeur junior qui maîtrise les flux agentiques dès sa première année peut surpasser un senior qui refuse de changer.

Si vous êtes en début de carrière, c'est votre moment. Saisissez-le.

Le futur : les organisations AI-native

Dans l'intervention d'Eric, Rem Koning — professeur à la Harvard Business School — prend du recul pour une vue au niveau organisationnel. Son insight recadre toute la conversation.

L'avenir des entreprises, selon Koning, dépend de la capacité à allouer l'intelligence. Pas seulement l'intelligence humaine. L'intelligence machine.

Les véritables organisations AI-native n'utiliseront pas simplement l'IA pour aider les développeurs à coder plus vite. Elles intégreront l'IA directement dans le produit — des agents qui interagissent avec les clients, traitent les commandes, gèrent le support et prennent des décisions sans humain dans la boucle.

Et puis vient la question à mille milliards de dollars : que se passe-t-il quand les agents IA commencent à se parler entre eux ?

Pas humain-à-agent. Agent-à-agent. Des systèmes autonomes qui négocient, collaborent et prennent des décisions à la vitesse de la machine. Ce n'est pas de la science-fiction — c'est l'étape logique suivante une fois que vous disposez d'agents fiables opérant dans des environnements bien structurés.

Les entreprises qui résoudront cela en premier n'auront pas seulement un avantage compétitif. Elles opéreront sur un plan fondamentalement différent.

Ce que vous devriez faire aujourd'hui

Si vous avez lu jusqu'ici, vous vous demandez probablement par où commencer. Voici une checklist pratique basée sur le cadre d'Eric :

Pour votre codebase :

Auditez votre couverture de tests. Les lacunes dans les tests sont des lacunes dans la capacité des agents.
Standardisez vos patterns. Une seule façon de faire chaque chose.
Mettez à jour votre documentation. Rendez-la exacte, pas aspirationnelle.
Supprimez le code mort et les conventions contradictoires.

Pour votre flux de travail :

Commencez avec un agent sur une tâche délimitée. Maîtrisez cela avant de passer à l'échelle.
Construisez des boucles de feedback. Examinez le résultat de l'agent comme vous examineriez la PR d'un junior.
Suivez ce qui fonctionne et ce qui ne fonctionne pas. Tenez un journal des succès et échecs des agents.
Expérimentez chaque semaine avec de nouveaux outils et approches.

Pour votre carrière :

Investissez dans les fondamentaux (conception de systèmes, algorithmes) — ce sont votre filtre qualité pour le résultat des agents.
Pratiquez le changement de contexte entre plusieurs tâches parallèles.
Développez votre goût en livrant et itérant, pas seulement en codant.
Restez humble. Le meilleur flux de travail d'aujourd'hui ne sera pas le meilleur dans six mois.

La transition de l'écriture de code à la gestion d'agents n'est pas optionnelle. Elle est déjà en cours. La question est de savoir si vous allez la mener ou la rattraper.

Cet article est basé sur l'intervention de Mihail Eric "From Writing Code to Managing Agents" sur la chaîne EO, avec les insights du professeur Rem Koning de la Harvard Business School.