Devenir Applied AI Engineer : evals, harness et systèmes distribués
Un ingénieur de Varick Agents résume ce qu'un développeur doit apprendre pour passer du code déterministe aux agents probabilistes.
In brief
Ce guide, publié sur le blog de la startup Varick Agents, décrit les trois compétences qui distinguent un Applied AI Engineer d'un développeur classique : les evals, le harness engineering et la conception multi-agents. Sa thèse : le modèle apporte l'intelligence, mais tout ce qui le rend fiable relève de l'ingénierie. C'est une feuille de route concrète pour les développeurs qui veulent basculer vers les agents en production.
🍺 Bar-stool version
En gros, le modèle d'IA, c'est un stagiaire brillant qui te répond un truc différent chaque fois que tu lui poses la même question. Ton boulot, ce n'est pas de le rendre plus intelligent, c'est de construire autour de lui le bureau, les badges d'accès et le règlement intérieur pour qu'il ne vire pas deux fois le même salaire. Et dès que tu en embauches un deuxième, tu découvres que deux stagiaires raisonnables peuvent quand même s'écrire dessus, problème que les informaticiens ont réglé il y a quarante ans, mais sans stagiaires. Ce qui compte, c'est que le métier d'ingénieur IA ressemble beaucoup plus à de la plomberie sérieuse qu'à de la magie.
Key takeaways
- 1
Le basculement clé : passer d'une pensée déterministe (même entrée, même sortie) à une pensée probabiliste, où le même appel peut produire un résultat différent à chaque fois.
- 2
Une eval note deux choses séparément : le résultat final et la trajectoire, c'est-à-dire la liste ordonnée des outils appelés et des arguments passés.
- 3
Les vérifications déterministes attrapent les violations de sécurité, tandis qu'un second modèle muni d'une grille d'évaluation juge la qualité.
- 4
Un agent correct à 95 % mais qui touche un champ interdit dans 4 % des cas paraît excellent sur un score agrégé et pose de gros problèmes en production.
- 5
Le harness, tout ce qui entoure le modèle, comprend cinq briques : exécution des outils, gestion du contexte, état et mémoire, guardrails, et boucle d'agent.
- 6
Dès le deuxième agent, le problème devient un problème de systèmes distribués : qui possède quel état, qui peut écrire, quels outils peuvent être relancés sans risque.
- 7
Quatre remèdes empruntés aux systèmes distribués : principe d'écrivain unique, clés d'idempotence, préconditions sur les écritures et passages de relais explicites.
Du déterministe au probabiliste
L'auteur, ingénieur chez Varick Agents, a écrit le guide qu'il aurait voulu lire avant sa propre transition. Selon lui, le rôle d'Applied AI Engineer recouvre largement celui de développeur, mais ajoute quelques concepts que la plupart des ingénieurs doivent apprendre.
La différence fondamentale tient à la manière de penser. En développement classique, une entrée structurée produit de façon déterministe une sortie structurée, et une panne se trace. Avec un agent, on construit autour d'un appel non déterministe à un modèle.
Conséquence : le travail ne consiste plus seulement à construire le logiciel, mais à mesurer si le système se comporte comme prévu. D'où la place centrale des evals.
Evals : noter le résultat et le chemin
Une eval consiste à confier une tâche à l'agent, à le laisser tourner, puis à noter ce qu'il a fait. Il faut prouver deux choses : que le travail est correct, et que l'agent est resté dans ses limites.
Noter le résultat est la partie facile. Pour un agent de traitement de factures, le cas d'usage de l'auteur, il s'agit de vérifier que la facture arrive au bon endroit ou que le doublon est signalé.
Noter la trajectoire est plus subtil. Un agent peut bien classer une facture tout en modifiant des coordonnées bancaires ou en envoyant un paiement avant approbation. La trajectoire n'est qu'un log ; la noter revient à écrire des vérifications contre ce log, par exemple s'assurer que send_payment n'apparaît jamais avant un appel d'approbation.
Les deux notes doivent être rapportées séparément. L'auteur recommande pour approfondir les ressources de Lenny et de Hamel, puis un cours plus pratique sur les evals.
Le harness, l'essentiel du métier
Un modèle seul n'est pas un agent : il peut dire quelle action effectuer, mais pas l'exécuter en sécurité. Le harness est tout ce qui transforme un appel d'API en agent opérationnel.
Exécution des outils : le modèle émet une requête structurée en JSON, le harness la valide, exécute l'opération réelle et renvoie le résultat sous forme de texte. Gestion du contexte : décider ce que le modèle doit voir maintenant, ce qu'il faut résumer et ce qu'il faut retirer, faute de quoi l'agent se perd dans un historique inutile.
État et mémoire : les modèles sont sans état entre deux appels, tout ce dont l'agent doit se souvenir vit ailleurs, en base de données ou dans un enregistrement de tâche. Guardrails : le modèle peut demander une mauvaise action avec la même assurance qu'une bonne, donc le harness vérifie permissions et entrées, bloque l'inaccessible et route les étapes à risque vers des humains.
Le tout s'articule dans la boucle d'agent : construire le contexte, appeler le modèle, inspecter la réponse, exécuter l'outil si autorisé, stocker le résultat, mettre à jour le contexte, recommencer.
Plusieurs agents, un problème de systèmes distribués
Quand le workflow grossit, l'instinct est de découper en rôles : un agent qui cherche, un qui planifie, un qui exécute, un qui relit. Mais le deuxième agent fait passer l'unité de conception de l'agent au système.
Plusieurs boucles agissent alors sur le même environnement. Un agent peut mettre à jour le statut d'un client pendant qu'un autre planifie à partir de l'ancien statut. Chacun a pris une décision raisonnable ; c'est leur ordre qui pose problème.
La bonne nouvelle, selon l'auteur, est que les ingénieurs systèmes distribués ont résolu ces pannes il y a des décennies. Il suffit d'appliquer leurs solutions à des boucles qui contiennent un LLM.
Quatre recettes éprouvées
Principe d'écrivain unique : chaque état important n'a qu'un agent autorisé à y écrire, imposé au niveau des outils. Si seul l'agent d'exécution peut écrire dans le CRM, l'agent de recherche ne peut pas le corrompre, quelle que soit la qualité de son raisonnement.
Clés d'idempotence : chaque appel d'outil qui modifie un système externe porte une clé unique, et un appel répété renvoie le résultat initial au lieu de rejouer l'action. C'est le fonctionnement de l'API de Stripe, utile pour éviter un double paiement après un timeout.
Préconditions sur les écritures et passages de relais explicites : une écriture n'a lieu que si l'état attendu est toujours vrai (« Approved seulement si encore Pending »), et le travail circule sous forme de messages au schéma défini, ordonnés par un orchestrateur. Un agent doit recevoir sa tâche, pas la découvrir.
“Traditional software engineering trains you to think deterministically, while applied AI forces you to think probabilistically.”
“Deterministic checks generally catch the safety violations, whereas the judge model scores the quality.”
“An agent should receive its task, not discover it.”
Why it matters
Ce texte a le mérite de dégonfler le mythe du « prompt engineer » : l'essentiel du travail sur les agents en production ressemble à de l'ingénierie logicielle rigoureuse, avec des tests, des permissions, de l'idempotence et de la gestion d'état. La distinction entre score de résultat et score de trajectoire est particulièrement utile, car elle pointe un angle mort fréquent des benchmarks agrégés, où une faute de sécurité rare disparaît dans une moyenne flatteuse. Le rappel que les systèmes multi-agents relèvent des systèmes distribués est sain à l'heure où beaucoup d'architectures empilent des agents par réflexe. Il faut toutefois lire ce guide pour ce qu'il est : une introduction, explicitement doublée d'une annonce de recrutement (prime de cooptation de 20 000 dollars à la clé), qui survole chaque sujet et renvoie vers d'autres ressources pour la profondeur. Son principal apport est de fournir une carte mentale claire, pas un manuel.
For you
Put it to work on your sources.
Free: a month of articles and three sources of your own. Pro: the whole archive and your sources, from €8/month.
For your team
The same machine, on your topics.
A space in your colours, your watch angles, your curators. Pilot open to three companies.