Solomon Hykes annonce le grand goulot d'étranglement de la CI en 2026

Le 15 septembre 2026, Solomon Hykes, cofondateur de Docker et CEO de Dagger, publie le même texte sur LinkedIn et sur X sous le titre « The Great CI Bottleneck of 2026 »¹. Son diagnostic tient en une phrase : les agents de code produisent des pull requests plus vite que les plateformes d'intégration continue ne peuvent les tester, et louer des machines plus rapides ne réglera rien. Le texte tombe moins de vingt-quatre heures après un billet d'ingénierie d'Anthropic qui décrit une multiplication par vingt-cinq de ses jobs de CI en six mois². Il sert aussi de teaser à Dagger 1.0.

Ce que dit Hykes

Hykes constate que les agents de code écrivent et modifient du code plus vite que les plateformes de CI ne le testent. Les files d'attente s'allongent, les équipes réagissent en achetant des machines plus grosses, et la facture grimpe pour un gain qui s'érode à chaque nouvel agent mis en production¹.

La raison, selon lui, tient à la nature des jobs de CI : dans la plupart des entreprises, un job reste un script shell lancé sur une machine virtuelle. Il ne connaît ni les dépendances entre les étapes, ni ce qui a changé depuis la dernière exécution. Il repart de zéro à chaque commit. Multipliez le nombre de commits par dix et le coût suit la même pente, sans que la qualité du signal (tests verts, tests rouges) progresse d'un cran.

Hykes range donc le goulot d'étranglement parmi les problèmes logiciels : la couche qui exécute les pipelines n'a pas évolué au rythme de ce qu'elle exécute. Sa réponse est celle qu'il construit en open source depuis sept ans avec Dagger : des pipelines écrits en code, exécutés dans des conteneurs par un moteur qui connaît le graphe des opérations et ne recalcule que ce qui a changé. Il conclut sur un appel aux « CI nerds », dont il dit que 2026 est leur année, et sur l'arrivée prochaine de Dagger 1.0, première version stable après quatre ans et demi de versions 0.x¹.

Les chiffres qui donnent du poids au diagnostic

Le 14 septembre 2026, la veille du post, Sachin Malhotra, ingénieur chez Anthropic, publie sur claude.com « Agentic coding is straining CI ». Anthropic livre huit fois plus de code par trimestre qu'avant l'arrivée des agents, Claude écrit 80 % de ce code, le volume de tests a été multiplié par dix et le nombre de jobs de CI par vingt-cinq en six mois. Le service maison d'analyse d'impact des tests, qui ne relance que les tests concernés par un changement, a failli céder sous la charge : l'équipe l'a rafistolé trois fois avant de le refondre²³. Malhotra a répondu sous le post de Hykes pour dire qu'il partage à 100 % l'analyse d'un problème logiciel, accéléré par le code que produisent les agents⁴.

Le 16 juillet 2026, O'Reilly Radar publie « Coding Was Never a Bottleneck » à partir des données de CircleCI : le débit des workflows a progressé de 59 %, mais le débit de la branche principale a reculé de 7 % pour l'équipe médiane. Le taux de succès des builds tombe à 70,8 %, son plus bas niveau en cinq ans. Dans le même article, Fiona Fung, qui travaille sur Claude Code chez Anthropic, désigne la CI comme le nouveau goulot⁵.

Le 9 septembre 2026, DevOps.com mesure l'autre bout de la chaîne : la taille des pull requests a augmenté de 154 % en 2025 et encore de 51 % en 2026. L'IA est très présente en génération et en revue de code, très peu dans les pipelines eux-mêmes : 13 % d'adoption en CI/CD, 6 % dans les décisions de déploiement⁶. Depot avait posé l'équation dès le 2 février 2026 : quand une fonctionnalité se génère en vingt minutes, un pipeline de vingt minutes n'est plus acceptable⁷. Paul Dix, le 31 décembre 2025, annonçait une « divergence » 2026 entre les équipes qui accélèrent revue, tests et release, et celles qui s'étranglent⁸.

Pourquoi des machines plus rapides ne suffisent pas

Une machine plus rapide réduit la durée de chaque job. Elle ne réduit pas le nombre de jobs qui recalculent des choses inchangées. Quand un agent ouvre vingt-cinq fois plus de pull requests, une CI qui rebuild tout à chaque fois multiplie sa facture par vingt-cinq, cache ou pas cache au niveau des paquets. Anthropic a dû écrire elle-même son service d'analyse d'impact des tests parce que sa plateforme de CI ne savait pas quels tests relancer².

Ce que Hykes appelle une stack logicielle, c'est la liste de ce que ce service faisait à la main : un cache au niveau de chaque opération, pas seulement des dépendances ; une connaissance du graphe entre les étapes, pour paralléliser et pour ne relancer que l'aval d'un changement ; une exécution identique sur le poste du développeur, dans la CI et dans le sandbox d'un agent. Les plateformes de CI actuelles fournissent des runners et un langage de configuration. Ce travail-là, elles le laissent aux scripts.

Bazel, Nix et les « CI nerds » : les réactions

Les réponses au post viennent surtout de spécialistes des systèmes de build. Steeve Morin, ancien de Google et de Zenly, aujourd'hui sur zml, écrit que « the Great CI Bottleneck is a software problem », en le présentant comme une vue à contre-courant. Arian van Putten, du côté de Nix et de Mercury, rappelle que tous les laboratoires de frontière utilisent Bazel ou Buck pour cette raison. Tom Sydney Kerckhove répond que NixCI règle le problème à la racine. Hykes leur répond que Bazel et Nix ne se généralisent pas à toute la CI : il faut toujours les envelopper dans des scripts shell⁴. Marcos Nils, ingénieur chez Dagger et ancien Docker Captain, relaie l'appel aux « CI nerds » ; le compte officiel de Dagger cite le post.

Les commentaires sous la version LinkedIn portent sur l'adoption plutôt que sur le diagnostic, et elles recoupent les trois objections qu'une DSI posera à son tour. La première : le code jeté que produisent les agents crée surtout des cache misses, et un cache plus fin n'aide que si les entrées se répètent. La deuxième : migrer une flotte de fichiers YAML à l'échelle d'un grand compte n'est pas un projet d'après-midi. La troisième : la compatibilité avec l'existant, BuildKite et les autres plateformes déjà en place¹. Hykes propose une couche d'exécution qui s'installe sous la plateforme en place ; le coût de bascule, lui, reste à la charge de celui qui migre.

Un manifeste, et un teaser

Le calendrier est serré : le billet d'Anthropic sort le 14 septembre, le texte de Hykes le 15. Hykes tient ce discours depuis des années, en podcast comme en conférence⁹, mais il dispose pour la première fois de chiffres tiers qui décrivent l'implosion qu'il prédit.

Le texte prépare aussi un lancement produit. La page d'accueil de dagger.io titre désormais « Faster machines won't fix your CI ». Le changelog de Dagger décrit Cloud Checks, un service en accès anticipé qui déclenche les vérifications à chaque événement Git sur des moteurs managés, et que l'équipe présente comme un remplacement complet de la plateforme de CI ; elle indique avoir débranché GitHub Actions pour sa propre CI¹⁰. La version stable 1.0, promise dans le post, viendrait fermer un cycle ouvert le 30 mars 2022 avec Dagger 0.2. Nous détaillons l'outil, son histoire et ses limites dans l'article compagnon « Dagger : la stack logicielle qui veut remplacer les scripts de votre CI ».

Ce qu'il faut regarder dans votre propre CI

Le diagnostic de Hykes se teste sur vos propres pipelines avec quatre mesures. Le rapport entre le temps de génération d'une fonctionnalité par un agent et le temps de votre pipeline : Depot fixe le seuil à un pour un⁷. Votre taux de succès des builds sur six mois, à comparer aux 70,8 % de CircleCI⁵. La part des minutes de CI consommées à recompiler ou retester du code qui n'a pas changé depuis la dernière exécution. Le coût de CI par pull request fusionnée, avant et après le déploiement d'agents de code dans vos équipes.

Ces quatre chiffres disent la même chose que le Rework Rate côté code : une vélocité de façade se paye ailleurs dans la chaîne. C'est aussi l'effet que DORA 2025 décrivait sous le nom d'amplification : une base saine multiplie les gains, une base fragile accélère le désordre. Anthropic a eu besoin de trois rustines et d'une refonte pour tenir une multiplication par vingt-cinq. La question que pose Hykes tient en une ligne : combien de fois votre CI a-t-elle recompilé, cette semaine, du code qui n'avait pas changé ?

Sources

1. Solomon Hykes, « The Great CI Bottleneck of 2026 », 15 septembre 2026 : post LinkedIn (et ses commentaires) ; X Article ; post X.
2. Sachin Malhotra, « Agentic coding is straining CI. Here's how we scaled test impact analysis at Anthropic », claude.com, 14 septembre 2026. claude.com
3. « Claude writes 80% of the code – and Anthropic's CI had to be patched three times », Clauding.de, 15 septembre 2026. clauding.de
4. Réactions publiques au post, 15-16 septembre 2026 : Sachin Malhotra (Anthropic), Steeve Morin, Arian van Putten, Tom Sydney Kerckhove, Marcos Nils (Dagger), @dagger_io.
5. « Coding Was Never a Bottleneck », O'Reilly Radar, 16 juillet 2026 : données CircleCI et déclaration de Fiona Fung. oreilly.com
6. « AI Has Turned Verification Into the New DevOps Bottleneck », DevOps.com, 9 septembre 2026. devops.com
7. « The bottleneck has shifted from writing code to integrating it », Depot, 2 février 2026. depot.dev
8. Paul Dix, « 2026: The Great Engineering Divergence », LinkedIn, 31 décembre 2025. linkedin.com
9. Heavybit, Open Source Ready ep. 17, « AI Native Software Factories with Solomon Hykes » (heavybit.com) ; The Kubelist Podcast ep. 37, « Dagger with Solomon Hykes », 28 juin 2023 (heavybit.com).
10. Dagger, page d'accueil et changelog (Cloud Checks, moteurs managés), relevés le 16 septembre 2026. dagger.io ; dagger.io/changelog