Construire Bencher en 2026 : open source, autofinancé et converti aux agents

Everett Pompeii

Cet essai a été initialement soumis au concours The Pragmatic Engineer’s How Software Engineering is Changing Essay Challenge le 4 octobre 2026.

Cette année a marqué un changement radical dans ma façon de construire des logiciels. Je suis ingénieur logiciel de niveau staff. Au cours des six dernières années, j’ai travaillé professionnellement en Rust, à la fois pour une licorne soutenue par YC et a16z et pour une entreprise du Fortune 500. En tant que développeur C++ repenti, j’ai été attiré par la profondeur et le savoir-faire qu’exigeait Rust. J’étais devenu un artisan expert dans l’art de ciseler à la main des logiciels systèmes temps réel. Au cours des dix derniers mois, j’ai dû enterrer cette identité. Même si mon intitulé de poste indique toujours “ingénieur logiciel”, mon métier est désormais celui d’“ingénieur de contexte”.

Ces quatre dernières années, j’ai passé mes soirées et mes week-ends à construire une entreprise open source et autofinancée, Bencher. Bencher est une plateforme de benchmarking continu qui aide les ingénieurs en logiciels systèmes à détecter les régressions de performance avant qu’elles ne soient fusionnées. Il faut toute une suite d’outils pour y parvenir : un CLI, un serveur API et une console web frontend. Chacun de ces composants a été écrit, à une erreur d’arrondi près, par moi. J’ai eu quelques contributeurs open source notables au fil des années, mais la grande majorité de Bencher le projet open source et 100 % de Bencher l’entreprise ont été conçus et implémentés par moi-même.

Pendant ces quatre années, je n’ai pas non plus vécu dans une grotte. Je me suis fiancé, marié, et j’ai eu mon premier enfant. Il me fallait des semaines, et parfois des mois, pour venir à bout de l’implémentation d’une grosse fonctionnalité et la déployer. Je devais jongler entre le développement et le support. Bencher avait déjà de nombreux utilisateurs, alors je passais pas mal de temps à répondre aux questions et à corriger le bug occasionnel.

En 2022, mon utilisation des LLM se résumait à la version gratuite pour Rust de TabNine, un outil de développement d’autocomplétion par tabulation créé par un étudiant, l’un des premiers stagiaires d’OpenAI, qui travaillait sur un drôle de petit projet nommé Codex. Une fois GitHub Copilot lancé, avec un support officieux de Rust, j’ai mis la main au portefeuille : 10 $/mois pour une licence personnelle.

C’était laborieux. Mais ça ressemblait quand même un peu à de la magie. Je me souviens avoir été bluffé, peu après l’ajout du chat à l’extension VSCode de GitHub Copilot, par sa capacité à créer des macros procédurales Rust. En général, je devais un peu retoucher le résultat, mais à quelques reprises, il a réussi du premier coup. Dingue ! C’était cool et ça m’a probablement fait gagner un peu de temps, mais je travaillais encore essentiellement de la même manière qu’avant.

À partir de là, j’étais convaincu que Microsoft était à l’avant-garde avec GitHub Copilot. Même si ces nouveaux labos dernier cri balançaient des “agents” à tout-va, je pouvais compter sur GitHub Copilot pour suivre le mouvement s’il y avait quoi que ce soit d’intéressant. J’entendais des gens comme Dan Shipper sur le Lenny’s Podcast, et leur description des capacités des modèles ne collait tout simplement ni avec mon expérience ni avec mon niveau d’exigence.

Au début de l’année dernière, j’ai écrit un article revenant sur trois ans de développement de Bencher, Revue d’Ingénierie : Édition 2025. Dans cet article, je passais en revue toutes mes grandes décisions d’ingénierie pour construire Bencher : frontend, backend, environnement de développement, CI, et j’en passe. J’ai consacré un paragraphe entier à pester contre la difficulté que j’avais eue, deux ans plus tôt, à comprendre CUE lang. Pourtant, il n’y a pas une seule mention de l’IA, des LLM, ni même de Copilot dans ces 3 500 mots.

Avance rapide, moins d’un an plus tard, et me voilà à compatir avec We mourn our craft.

Claude aide à sauver Noël

Comme beaucoup d’autres, pendant les vacances d’hiver 2025, j’ai eu l’occasion de vraiment utiliser Claude Opus 4.5. J’étais à Londres avec ma femme et mon enfant, chez ma sœur et sa famille. Ma sœur venait de donner naissance à des jumeaux, donc j’étais censé être là pour donner un coup de main. Au lieu de ça, j’étais terré à l’étage à essayer de repousser du spam par e-mail et des attaques DDoS contre Bencher. Claude a été super utile pour diagnostiquer ce qui se passait et imaginer des solutions possibles.

J’ai fini par migrer Bencher derrière Cloudflare et par mettre en place reCAPTCHA. C’était encore moi qui faisais l’essentiel du travail, mais Opus 4.5 marquait un net progrès dans sa capacité à résoudre des problèmes face à de nombreuses contraintes de conception concurrentes. Cela dit, il m’a bien suggéré un changement qui a rendu inutilisable le script pratique d’installation du CLI Bencher pendant une demi-journée. Oups.

Nouvelle année, nouveau harnais

En janvier de cette année, ça faisait des mois que j’entendais dire à quel point Claude Code était impressionnant. Je m’étais retenu de l’essayer jusque-là parce qu’Opus 4 n’atteignait tout simplement pas mon niveau d’exigence pour que je fasse confiance à son travail. Maintenant qu’Opus 4.5 avait franchi ce cap, je voulais aussi donner sa chance à Claude Code. Le bond en avant que j’ai constaté en passant de Copilot à Claude Code comme harnais était tout aussi grand que celui en passant d’Opus 4/GPT-5.2/Gemini 2.5 Pro à Opus 4.5 comme modèle.

Dès mon tout premier week-end avec Claude Code, j’ai fait un test pas très contrôlé face à Copilot. Je voulais que Copilot transforme un PDF en livre audio. Même en “Agent Mode”, Copilot avançait de cinq ou six étapes puis s’arrêtait tout simplement jusqu’à ce que je le relance. Pendant ce temps, Claude Code bossait d’arrache-pied à construire un hyperviseur sur mesure, après être passé par un Plan mode approfondi. J’ai acquis la conviction absolue que le niveau d’abstraction était monté du modèle au harnais et que Copilot ne rattraperait plus jamais son retard.

Rêver de Bencher Bare Metal

Depuis les tout débuts de Bencher, je rêvais de construire une flotte de benchmarking sur bare metal. Les runners de CI traditionnels, du fait même qu’ils sont des machines virtuelles, ont trop de bruit pour vous donner des résultats de benchmark cohérents. Vous pourriez détecter, disons, une hausse de 200 % de la latence, mais vous ne pourriez jamais détecter une hausse de 20 % de manière fiable. Le comptage d’instructions est une possibilité pour le benchmarking en CI. Il est en grande partie déterministe. Cependant, le nombre d’instructions n’est qu’un indicateur indirect de ce qui vous importe vraiment : le temps réel écoulé. Tout ce qui s’exécute dans une “simulation de CPU” et recrache des nombres d’instructions ne peut qu’être corrélé à la vitesse. Le problème, c’est que vous ne savez jamais de combien il se trompe, beaucoup ou peu, à moins de mesurer réellement sur bare metal.

L’un des tout premiers utilisateurs de Bencher a été le projet Rustls. J’ai contribué à leur Rustls bench runner. Cependant, ce n’était pas une bonne fondation sur laquelle bâtir une flotte de benchmarking sur bare metal. Il tournait sur un seul hôte et considérait toutes les charges de travail de benchmark comme fiables. Cela veut dire pas de PR provenant de forks et pas de multi-location. En plus, la plupart des équipes ne veulent pas payer plus de 100 $ par mois par serveur de benchmarking bare metal.

J’avais envisagé d’utiliser GitHub Actions pour la couche d’orchestration, mais cette approche présentait quelques défauts fondamentaux. Pour commencer, le GitHub Actions Runner est écrit en C#. Cela signifie que son ramasse-miettes peut se déclencher au milieu de votre exécution et fausser vos résultats de benchmark. Ah, et pensez à désactiver la mise à jour automatique pour qu’elle ne se déclenche pas en pleine exécution, mais ne l’oubliez pas trop longtemps, sinon vos jobs cesseront de s’exécuter !

Même si le GitHub Actions Runner avait été un joli binaire Rust bien silencieux, le problème plus fondamental était qu’il était lié à GitHub Actions. Depuis le début, Bencher est pensé CLI d’abord. Pour le meilleur ou pour le pire, je n’ai jamais voulu lier Bencher trop étroitement à un fournisseur de CI en particulier. Il existe une GitHub Action pour le CLI Bencher, mais tout ce qu’elle fait, c’est installer le CLI pour vous. Je voulais que Bencher Bare Metal fonctionne partout où le CLI fonctionne, pas seulement dans GitHub Actions.

L’idée qui m’est venue était d’utiliser des images OCI pour empaqueter la charge de travail de benchmarking, avec un bac à sable optionnel et très léger, pour n’exécuter qu’un seul job à la fois sur un hôte bare metal donné. La perspective de construire tout ça seul, sur mes soirées et mes week-ends, était intimidante. Avec un emploi de jour et une famille, il m’aurait fallu au moins un an à grignoter le projet petit à petit tout seul.

Construire Bencher Bare Metal

Avec Opus 4.5 et Claude Code en main en janvier de cette année, j’avais l’impression de voir enfin un chemin concret pour construire Bencher Bare Metal. J’ai de nouveau mis la main au portefeuille, cette fois à hauteur de 200 $/mois pour l’abonnement Claude Max 20x. Probablement la meilleure dépense professionnelle de tous les temps.

Je me suis mis à carburer à fond et j’ai fait de mon mieux pour épuiser chaque semaine le quota de mon abonnement Claude. J’ai arrêté d’écrire du code à la main, aussi bien sur Bencher qu’à mon travail de jour. À ce stade, j’itérais encore en boucles assez serrées, en utilisant le Plan mode, en lisant toute la sortie et en travaillant en mode Accept edits. Je ne faisais pas encore confiance à l’agent pour toucher à git/jj, donc je gérais moi-même tout le contrôle de version. Je me voyais comme une Ralph Loop avec un humain dans la boucle. À partir de cinq agents environ en parallèle, mon cerveau commençait à fondre.

Une suggestion que j’avais entendue était de confier l’implémentation et la revue à des agents distincts, alors j’ai commencé à faire des revues contradictoires séparées. Ces revues contradictoires semblaient vraiment améliorer la qualité du résultat. J’ai créé mon propre bot de revue GitHub Actions qui utilisait la clé API de mon abonnement Claude Code. Je faisais ensuite itérer mon agent local avec ce relecteur en CI pour économiser des cycles sur ma machine locale.

À un moment donné, j’ai cru que j’allais demander à Claude de construire son propre hyperviseur pour le bac à sable de benchmarking. J’ai alors demandé à Claude de faire une revue contradictoire du plan dans la peau de Linus Torvalds, et il m’a répondu que j’étais stupide et que c’était une idée très, très, très bête. Pas de complaisance quand Linus est dans votre contexte ! Alors j’ai abandonné ce plan et je suis parti sur Firecracker.

L’ennemi d’un bon benchmarking, c’est la variance, pas la vitesse en soi. Donc même si Firecracker ajoute un surcoût en tant qu’hyperviseur, c’est un surcoût très constant, surtout avec une seule microVM en cours d’exécution à la fois. Cela permet aux runners partagés de Bencher Bare Metal d’offrir à la fois la multi-location et des résultats de benchmark très cohérents. J’ai aussi travaillé avec Claude en Plan mode pour concevoir les choses de sorte que le bac à sable soit optionnel. Si un utilisateur veut exécuter ses benchmarks sur son propre serveur dédié, où il fait confiance à chaque charge de travail, alors il peut se passer de Firecracker avec un surcoût quasi nul.

Développer le runner de Bare Metal a été une grande leçon pour moi sur l’importance pour les agents d’avoir une boucle de rétroaction courte. Même après la sortie d’Opus 4.6, Claude semblait avoir du mal à faire fonctionner le tout de manière fiable. Une fois que je lui ai donné accès à un environnement de développement avec KVM activé (nécessaire pour faire tourner Firecracker), les choses ont vraiment commencé à se mettre en place. Ces agents ne sont pas omniscients, ils sont juste vraiment tenaces.

Le niveau d’examen auquel je soumettais le travail de Claude dépendait de la partie de la base de code dans laquelle il travaillait. Le code purement dédié à Bare Metal, comme le registre OCI et le binaire runner, je ne l’ai relu que légèrement. Tant qu’il passait la revue contradictoire, que les tests de bout en bout passaient et que les choses n’avaient pas l’air trop horribles, je fusionnais. Pour le code qui touchait au cœur existant, la mise en file d’attente des jobs et le traitement des rapports, j’étais aussi tatillon que jamais.

Fin mars de cette année, j’ai publié Bencher Bare Metal dans le cadre de la v0.6.0. Pour la flotte bare metal publique, j’envisageais d’utiliser AWS EC2 Bare Metal. Cependant, ces machines sont à la fois énormes et uniquement ARM. Pour correspondre à la plupart des charges de travail du monde réel, je voulais de bonnes machines Intel x86 prolétaires. J’ai cherché avec Claude le meilleur foyer pour la flotte qui respecterait les contraintes de conception. Nous avons fini par pouvoir proposer sur Bencher Cloud la Spec intel-v1, qui offre aux utilisateurs 4 vCPU, 48 Go de mémoire et 128 Go de disque, facturés à la minute. Sur des benchmarks bien structurés, j’obtenais systématiquement une variance <2% entre les exécutions sur l’ensemble de la flotte.

Authentification des agents

Jusqu’à Bencher Bare Metal, toute l’authentification reposait sur des JWT. De gros, beaux et incompréhensibles JWT. L’authentification des runners Bare Metal, elle, utilisait une clé API préfixée par un nom, par ex. bencher_runner_abc123....

Côté client, je voulais donner aux agents autre chose à utiliser que le jeton API JWT de l’utilisateur lui-même. Le compromis que j’ai trouvé a été d’enfin implémenter une fonctionnalité demandée depuis longtemps : l’authentification à l’échelle du projet. Claude m’a aidé à créer des clés API de projet sécurisées et préfixées. Ces clés API sont restreintes à des permissions équivalentes à ce qu’effectue la commande CLI bencher run : des lectures limitées au projet et des écritures non destructives. Cela fait aussi de ces clés API un choix naturel pour les workflows de CI de benchmarking continu.

Plus tard, quand j’ai ajouté le Bencher MCP, ces clés API de projet ont aussi servi à l’authentification. Le standard MCP désigne OAuth 2.1, mais celui-ci est encore à l’état de brouillon, donc je ne voulais pas encore l’implémenter. Honnêtement, je suis un peu sceptique vis-à-vis du MCP. Je pense toujours qu’un bon CLI + des skills est une manière plus efficace et plus portable d’exposer un service à un agent. Le plus gros problème des CLI, cependant, c’est l’absence de mécanisme d’authentification standard. Donc même si OAuth 2.1 est encore à l’état de brouillon, au moins le MCP couvre ce point. Et une bonne solution d’authn compte vraiment pour les entreprises.

Claude le polyglotte

En 2023, j’ai décidé que je voulais que la documentation de Bencher soit disponible en 9 langues : anglais, chinois, espagnol, portugais brésilien, russe, japonais, français, allemand et coréen. Comment ai-je choisi ces neuf langues ? Ce sont les langues dans lesquelles la documentation de GitHub était disponible, alors je me suis dit que c’était une approximation suffisante. Le seul problème, c’est que je ne parle couramment que l’anglais. J’ai donc fait traduire la documentation par GPT-4. À l’époque, GPT-4 n’avait qu’une fenêtre de contexte de 8k tokens. Cela signifiait que je devais découper toutes mes pages de documentation en “chunks” de moins de 8k tokens. Ensuite, j’ai dû créer un outil CLI pour gérer la traduction, et très souvent la retraduction, des chunks après leur mise à jour.

C’était un processus très fastidieux et sujet aux erreurs. Je devais retoucher à la main les fichiers traduits parce que, même avec des instructions très explicites dans le prompt système, le modèle massacrait quand même les chemins d’import ou fourrait tout dans une couche supplémentaire de bloc Markdown, surtout en japonais, allez savoir pourquoi.

Une fois que j’ai commencé à utiliser Claude Code avec Opus 4.5, tout cela a disparu. Maintenant, l’agent s’en charge, tout simplement. La convention qui définit ce qu’est un chunk se trouve dans la base de code, et Claude la suit, tout simplement. Quand j’ai rédigé la documentation technique de Bencher Bare Metal, Claude s’est simplement occupé du découpage en chunks et de l’orchestration des traductions. Même si la taille du contexte est désormais largement suffisante pour gérer une page entière, j’aime avoir les chunks. Ils permettent de garder les changements isolés, de sorte que seules les sections pertinentes d’une page sont retraduites lors d’une révision.

Qui n’a pas construit de harnais en 2026 ?

Tout en construisant Bencher Bare Metal, j’ai aussi demandé à Claude de créer ses propres outils pour gérer la flotte. Cela se composait de deux parties : un CLI dans le dépôt bencher pour les tâches de routine et un nouveau méta-dépôt. Ce méta-dépôt contient toute la documentation et tout le contexte de Bencher en tant que produit. Chaque autre dépôt de l’organisation GitHub bencherdev est un sous-module de ce méta-dépôt. Le méta-dépôt permet à l’agent de travailler facilement sur une tâche qui peut s’étendre sur plusieurs dépôts et de rédiger des documents que je préfère ne pas rendre publics (stratégie produit, rapports d’incident, etc.).

Je voulais construire mon propre agent par-dessus le CLI Claude Code, qui ferait passer ce méta-dépôt du statut d’artefact à celui de partie proactive du cycle de développement. Une fois Fable 5 disponible, j’ai concentré une grande partie de mon énergie sur la construction de cet agent. Je voulais pouvoir faire confiance à cet agent pour fonctionner de manière autonome. Une grande partie de cela tenait à la sécurité (c.-à-d. atténuer les injections de prompt). Je l’ai conçu de sorte que les agents de travail ne détiennent jamais aucun secret. Tous les secrets sont injectés par un proxy réseau et restreints à des points de terminaison sur liste blanche. Les agents eux-mêmes tournaient dans encore une autre microVM Firecracker, cette fois avec du parallélisme. La machine de contrôle des agents et le proxy réseau + les bacs à sable tournaient sur des hôtes complètement différents.

Ma grande vision était que l’interface soit une file d’attente classée par priorité des tâches. Autrement dit, le but de cet agent serait de me montrer la tâche la plus importante à un instant donné. Là où les fils d’actualité de Facebook/Instagram/Twitter/X/TikTok sont optimisés pour l’engagement, ce fil serait optimisé pour ce qui est important pour moi.

Je voulais créer l’outil qui me placerait en dessous de l’API. Je m’étais rendu compte que je passais le plus clair de mon temps à changer de contexte et à sauter d’un fil à l’autre. J’espérais que l’agent pourrait m’aider à alléger ce jonglage en classant les choses par ordre d’importance pour moi. Avec un système de votes positifs/négatifs à la Reddit, je pourrais entraîner l’agent à savoir si ce nouveau message Slack était vraiment la chose la plus importante à laquelle prêter attention.

Je me suis aussi rendu compte qu’une grande partie de mon travail consiste désormais à être le Rubeus Hagrid de mon agent, son “gardien des clés”. L’injection au niveau du proxy réseau avec une liste blanche restreinte de points de terminaison était la meilleure solution que Claude et moi ayons trouvée pour à la fois empêcher l’agent d’avoir jamais accès à un secret et lui permettre quand même d’utiliser des outils comme le CLI gh tels quels.

L’autre objectif phare était de ne jamais quitter l’interface de l’agent. Quitter l’agent pour quelque raison que ce soit est considéré comme un échec du harnais. J’ai créé un système de composants d’UI procédural pour que l’agent travaillant sur une tâche puisse construire une interface inédite à la volée ou choisir l’un des composants existants de la bibliothèque en fonction de la tâche en cours. Code, e-mail, Slack, agenda, données de télémétrie de production, suivi des erreurs, tout dans une seule interface, tout dans une seule file d’attente priorisée.

J’ai mis en route une version minimale de tout cela. Cependant, il reste encore beaucoup d’aspérités. Pour l’instant, je suis bien plus productif si j’utilise simplement l’application de bureau Claude. Et en ce moment, j’ai besoin de toute la productivité immédiate possible pour suivre la demande.

Que se passe-t-il quand le nombre de développeurs est multiplié par 100 ?

En 2022, je cherchais un nouveau projet parallèle. J’avais mis fin à ma précédente aventure d’apprenti entrepreneur en 2020. Conseil de pro : écoutez Jason Cohen, n’essayez pas d’autofinancer une marketplace.

À mon travail de jour, je construisais en Rust un parseur et analyseur statique de bash, et je me suis retrouvé à devoir utiliser un tableur pour suivre mes résultats de benchmark. Le projet Rust dispose de rustc-perf pour suivre les performances du compilateur lui-même. Pourtant, il n’existait pas de bon outil pour faire la même chose sur mon propre code.

J’ai fait énormément de recherches sur l’art antérieur dans le domaine. Pendant plusieurs mois, j’ai eu des appels avec plusieurs développeurs qui avaient soit construit, soit défendu la construction d’outils de benchmarking continu. Tout le monde réinventait la roue. Je pensais avoir trouvé un joli coin tranquille dans les eaux du marché. Il y avait un besoin évident et permanent. Beaucoup d’équipes payaient déjà plus de 100 $/mois pour leurs propres runners bare metal. Il y avait donc une volonté de payer. Pourtant, le cas d’usage était de niche. La plupart des logiciels modernes sont déployés en tant que service, donc faire du shift left sur les tests de performance n’était pas vraiment une priorité pour la plupart des équipes. Elles se contentaient de configurer des alertes dans Grafana après le déploiement et de rattraper après coup tout ce qui serait passé entre les mailles du filet.

Avec l’arrivée d’agents très performants, cependant, deux facteurs ont considérablement augmenté l’utilisation de Bencher :

1. Le besoin d’adopter les bonnes pratiques du génie logiciel afin de tester de manière déterministe la production des agents
2. La facilité d’adopter les bonnes pratiques du génie logiciel avec l’aide des agents

Les LLM, et par extension les agents, sont des systèmes non déterministes et stochastiques. Comme les développeurs humains, ils ont besoin de garde-fous pour s’assurer qu’ils maintiennent la qualité du code. Les moyens d’y parvenir ne sont pas nouveaux : un système de types robuste, un formateur standard, un linter réglé sur 11, des tests, des tests et encore des tests. Le tout exécuté en CI. Pour les charges de travail sensibles aux performances, ces tests incluent des benchmarks qui sont suivis. Suivre les performances d’un logiciel dans le temps vous permet de détecter les régressions de performance en CI. C’est ce qu’on appelle le benchmarking continu. Mettre en place le benchmarking continu a toujours été un peu une corvée. Seules les équipes qui tenaient vraiment, vraiment aux performances le faisaient, et elles faisaient d’excellents utilisateurs de Bencher !

Avec l’avènement des agents, cependant, le coût d’ajout du benchmarking continu à votre workflow avec Bencher ne tient plus qu’à un court prompt. C’est difficile à mesurer précisément, mais je parierais que la grande majorité des inscriptions entrantes de Bencher viennent désormais de la recommandation d’un agent, ou d’un agent qui s’inscrit lui-même. Ce sera de plus en plus vrai avec le temps, à mesure que davantage de développeurs adopteront des agents et leur donneront les moyens du commerce agentique. Que ce soit ou non le protocole x402, je pense qu’une grande partie des dépenses en outils de développement passera à l’avenir par des agents. Je vous recommande de réserver votre Cloudflare Wallet et votre Stripe Wallet, si ce n’est pas déjà fait.

Presque tous les outils de développement devront passer à une tarification à l’usage à l’ère agentique. La tarification par siège n’a aucun sens quand ce sont les agents qui utilisent votre service. Bencher a toujours eu une tarification à l’usage. Cependant, avec l’aide de Claude, j’ai récemment remanié le modèle de tarification pour le rendre encore plus adapté aux agents. Auparavant, Bencher facturait par Métrique. Une Métrique est un résultat de benchmark unique à un instant donné. Par exemple, si vous avez 1 benchmark et que vous l’exécutez 5 fois, cela crée 5 Métriques. Claude m’a aidé à analyser les retours des utilisateurs et les schémas d’utilisation. J’en suis arrivé à la conclusion que l’unité utilisée pour notre modèle de tarification à l’usage devait changer. Désormais, Bencher facture par Série de Benchmark. Une Série de Benchmark est un benchmark suivi dans le temps. Pour reprendre notre exemple, si vous avez 1 benchmark et que vous l’exécutez 5 fois, cela fait 1 Série de Benchmark. Ce nouveau modèle de tarification offre beaucoup plus de prévisibilité aux utilisateurs. Vous pouvez confier un problème d’optimisation à un agent, et il peut faire du hill climbing sur vos benchmarks historiques sans engendrer le moindre coût supplémentaire.

L’une des choses que je n’ai pas vues changer cette année, ce sont les contributions open source. Bencher a reçu quelques PR d’AI slop. Le principal problème de ces PR, c’est qu’elles corrigeaient des bugs aléatoires, sans rapport, trouvés en chemin. Mais c’étaient quand même de vrais bugs ! Alors j’ai un peu haussé les épaules et j’ai fusionné les PR, après les avoir fait relire par mon propre agent, bien sûr. C’est un peu triste, mais je ne vois plus vraiment l’intérêt de courtiser les contributeurs open source. Que ce soient leurs tokens ou les miens, je dois quand même fournir le même effort pour relire le code. Il me faut désormais beaucoup plus d’énergie pour relire la PR d’un contributeur que pour itérer moi-même avec Claude.

Quel est l’avenir du Benchmarking Continu ?

Quand on essaie de deviner ce que l’avenir nous réserve, la règle semble être de regarder ce que font les laboratoires de pointe eux-mêmes. Nous y serons tous d’ici six à douze mois, semble-t-il. L’article de The Pragmatic Engineer Inside OpenAI’s agentic software factory apporte un éclairage intéressant sur ce sujet du point de vue du benchmarking continu :

Nouveau : un “perf harness” : l’agent utilise aussi un perf harness pour envoyer les PR problématiques au framework A/B Synthetics afin d’évaluer leurs implications sur les performances. Comme mentionné plus haut, la charge sur les systèmes de CI a fortement augmenté au cours des six derniers mois.

Le “perf harness” d’OpenAI semble très similaire à la pratique établie du benchmarking continu relatif. La nouveauté apportée par l’IA, c’est la partie synthétique du framework A/B. Les données de test synthétiques n’ont rien de nouveau. Mais pouvoir façonner de manière autonome ces données synthétiques pour évaluer les performances du changeset en question, ça, c’est clairement nouveau ! Faire en sorte qu’un développeur écrive réellement les benchmarks a toujours été le point difficile. Maintenant, c’est automatisé. De la même manière que les agents ont considérablement augmenté la couverture des tests fonctionnels, ils nous permettent aussi d’augmenter considérablement la couverture des tests de performance.

OpenAI n’est pas seul dans cette quête. Anthropic a publié peu après How we made claude.ai 3x faster in two weeks. Ils y décrivent eux aussi la construction de benchmarks à la volée. Une différence clé est qu’Anthropic a trouvé des comptages déterministes corrélés aux performances : instructions, commits par interaction, appels de fonction, recalculs de style et mutations du DOM. Claude a ensuite fait du hill climbing sur ces comptages pour optimiser les performances de leur application. À la fin de la passe d’optimisation, ils ont vérifié que leurs optimisations basées sur les comptages se traduisaient réellement par des gains de temps réel écoulé dans le monde réel.

Ces méthodologies rejoignent ce que je vis personnellement en travaillant sur Bencher. Cela dit, mes tests de performance A/B ont tous été exécutés en local ou sur la machine de travail d’un agent, pas dans une boucle de CI. Chaque fois que je m’apprête à faire un changement important sur une requête ou une migration de schéma conséquente, je demande à Claude de faire une évaluation exhaustive des performances du changement. Cela inclut toujours le temps réel écoulé et parfois quelques comptages déterministes corollaires (par ex. les instructions de la machine virtuelle SQLite).

À cause des problèmes de voisins bruyants, ces passes d’optimisation des performances menées par des agents ont eu des barres d’erreur assez larges. Je cherche à ajouter des fixtures (entrées de benchmark supplémentaires) et des artefacts (sorties de benchmark supplémentaires) à Bencher Bare Metal afin de mieux permettre à mon agent d’exécuter ces tâches d’optimisation des performances avec un niveau de confiance plus élevé. L’agent fera toujours l’essentiel de son travail d’optimisation en local, en faisant du hill climbing du mieux qu’il peut sur le temps réel écoulé ou sur des comptages déterministes. Ensuite, il utilisera Bencher Bare Metal pour vérifier son travail, comme une sorte de pied à coulisse du temps réel.

Même si je pense que la plupart des “utilisateurs” de Bencher seront des agents d’ici un an environ, je pense toujours que la plupart des humains voudront une interface visuelle quand ils viendront jeter un œil. Je suis actuellement plongé jusqu’au cou dans une refonte totale de l’interface de Bencher avec l’aide de Claude. Écrite par un ingénieur Rust qui faisait de l’Anyscript à l’époque de l’autocomplétion par tabulation de GitHub Copilot, l’interface actuelle laisse beaucoup à désirer. La réécriture de l’interface est cependant bloquée par un autre chantier encore plus ambitieux : une nouvelle version du Bencher Metric Format (BMF).

Le BMF est le format central dans lequel les résultats de benchmark sont normalisés au sein de Bencher. Il traverse tout. Cette nouvelle version du BMF permettra de paramétrer les benchmarks. Vous pourrez déclarer my_benchmark avec les paramètres size: 16 MB et size: 32 MB, au lieu d’avoir deux benchmarks distincts, my_benchmark_16_mb et my_benchmark_32_mb. La nouvelle version du BMF permettra aussi des noms de métriques arbitraires. Vous pourrez fournir des métriques mean, p95 et p99 pour vos mesures Latency, au lieu de n’avoir que mean ou de devoir créer Latency (mean), Latency (p95) et Latency (p99) comme mesures distinctes.

Prendre en charge cette nouvelle version du BMF représente une refonte massive du cœur de Bencher. Je ne me serais pas senti à l’aise de faire ce travail avec quoi que ce soit d’antérieur à Fable 5. Comme évoqué plus haut, l’essentiel du travail sur Bare Metal était orthogonal au cœur de Bencher : suivre les performances dans le temps et alerter en cas de régression. Le BMF est au centre de cette proposition de valeur. Ma confiance en Fable 5, et plus encore en Fable 5.1 et Opus 5.5, m’a de nouveau permis de démarrer un projet qui m’aurait demandé des années de soirées et de week-ends. Auparavant, j’avais dû passer pas mal de temps à optimiser SQLite pour Bencher. Maintenant, chaque fois que je fais évoluer le modèle, je demande simplement à Claude de lancer un agent pour mener une enquête approfondie sur les performances, afin de m’assurer que tout reste performant. À l’avenir, je ne pense même pas que j’aurai à le demander.

Comment je code aujourd’hui

À l’époque où j’utilisais GitHub Copilot, c’était une extension dans VSCode. Quand je suis passé à Claude Code, j’utilisais le CLI. J’avais trois fenêtres de terminal, chacune dans son propre Space macOS. Chaque fenêtre de terminal avait deux onglets. Un onglet pour Claude, l’autre pour Jujutsu (jj). Je gérais encore moi-même le contrôle de version et les workspaces jj.

Aujourd’hui, j’utilise simplement l’application de bureau Claude Code. Chaque nouvelle session que je démarre part de mon méta-dépôt avec la case worktree cochée. J’ai arrêté d’utiliser le Plan mode il y a quelques mois. Je n’ai jamais installé le skill /grill-me de Matt Pocock. Je demande simplement à Claude de “me cuisiner sur toutes les décisions de conception” dans le prompt, et à ce stade le modèle sait quoi faire. Mon CLAUDE.md AGENTS.md est plutôt bien réglé sur la façon dont je veux que le modèle se comporte.

J’ai pratiquement mis hors service mon workflow de CI Claude Review. L’agent se charge désormais de lancer un relecteur contradictoire en local sans même que j’aie à le demander. Ensuite, ils itèrent jusqu’à converger, parfois jusqu’à une demi-douzaine de tours. J’ai commencé à expérimenter le transfert du travail de développement vers des machines de travail externes, en ne gardant ma machine locale que comme orchestrateur.

Les seules fois où je touche encore moi-même au contrôle de version, c’est quand j’essaie de récupérer un build pour tester des choses moi-même ou quand je crée une release taguée et versionnée de Bencher. Cela arrive environ une fois par semaine et une fois par mois, respectivement. À part ça, je laisse désormais Claude s’en occuper. J’utilise abondamment les PR en brouillon et, maintenant qu’elles sont disponibles sur GitHub, les PR empilées. Je ne regarde pas le code avant que la PR soit ouverte. Je parcours encore le code de Bencher, mais à ce stade c’est plus une vérification de bon sens qu’une véritable revue de code.

Quand, dans un an, je relirai ce que j’ai écrit ici, aurai-je un autre moment “Tu n’as même pas mentionné l’IA‽” ? Une moitié de moi se dit que ce serait génial. L’autre moitié est absolument terrifiée.

Bencher: Benchmarking Continu

Bencher est une suite d’outils de benchmarking continu. Avez-vous déjà eu une régression de performance qui a impacté vos utilisateurs ? Bencher aurait pu empêcher cela de se produire. Bencher vous permet de détecter et de prévenir les régressions de performance avant qu’elles ne soient fusionnées.

• Exécuter: Exécutez vos benchmarks localement ou en CI en utilisant exactement les mêmes runners bare metal et vos outils de benchmarking préférés. La CLI bencher orchestre l’exécution de vos benchmarks sur bare metal et stocke ses résultats.
• Suivre: Suivez les résultats de vos benchmarks au fil du temps. Surveillez, interrogez et graphiquez les résultats à l’aide de la console web Bencher en fonction de la branche source, du banc d’essai et de la mesure.
• Détecter: Détectez les régressions de performances localement ou en CI en utilisant exactement le même matériel bare metal. Bencher utilise des analyses de pointe et personnalisables pour détecter les régressions de performances avant qu’elles ne soient fusionnées.

Pour les mêmes raisons que les tests unitaires sont exécutés pour prévenir les régressions de fonctionnalités, les benchmarks devraient être exécutés avec Bencher pour prévenir les régressions de performance. Les bugs de performance sont des bugs !

Commencez à détecter les régressions de performances — essayez Bencher Cloud gratuitement.