S’attaquer à la dette technique à grande échelle avec le mode autonome de Kiro Web

Toutes les équipes de développement logiciel ont connu la tension entre la maintenance et la création de nouvelles fonctionnalités : le temps consacré à l’une est du temps qui n’est pas consacré à l’autre. Pour les responsables de projets à code source ouvert, ce défi est encore plus aigu, avec des équipes plus petites, des bases d’utilisateurs plus grandes et un arriéré qui ne cesse de croître. En vérification formelle, l’utilisation de techniques mathématiques pour prouver des propriétés du logiciel et la complexité du domaine rendent la situation particulièrement pénible. Le groupe de raisonnement automatisé d’AWS maintient plusieurs outils de vérification formelle à code source ouvert, ou en est un contributeur principal, dont le vérificateur Rust Kani et le C Bounded Model Checker (CBMC). En novembre 2025, lorsque nous avons entrepris le travail décrit dans cet article, ces dépôts comptaient 916 problèmes ouverts, les tâches de maintenance s’accumulant plus vite que l’équipe ne pouvait les traiter tout en continuant de faire progresser les capacités de vérification de base.

Les approches traditionnelles de la dette technique forcent un choix entre affecter du temps de développement à la maintenance (et ralentir la livraison de fonctionnalités) ou laisser la dette s’accumuler. Les assistants de programmation IA interactifs aident à accélérer des tâches individuelles, mais exigent encore qu’un développeur soit activement impliqué à chaque étape. Nous voulions une troisième option qui prenne en charge une tâche de maintenance de bout en bout, de la lecture du problème à l’ouverture d’une pull request, de sorte que les ingénieurs n’interviennent qu’à la révision du code, là où leur jugement compte le plus. Cet outil est le mode autonome de Kiro dans Web, un outil d’ingénierie logicielle agentif capable d’accomplir une gamme de tâches, y compris la maintenance, pendant que les ingénieurs se concentrent sur du travail à plus forte valeur. Voici ce à quoi cela ressemble en pratique. En deux mois, Kiro a soumis des pull requests traitant 87 problèmes ouverts dans nos dépôts, un volume qui approche ce que l’équipe avait traité au cours des 22 mois précédents (environ 2 ans).

Dans cet article, nous décrivons comment nous avons mis cela en place, présentons deux études de cas en détail et expliquons comment utiliser Kiro de façon autonome sur votre propre dépôt.

Kiro en mode autonome fonctionne de manière autonome dans son propre environnement de développement infonuagique sécurisé tout en s’intégrant aux flux de travail existants. Confier du travail à Kiro est simple : décrivez la tâche sur app.kiro.dev, ajoutez l’étiquette kiro à un problème GitHub, ou mentionnez /kiro dans un commentaire. Kiro clone ensuite le dépôt dans un bac à sable isolé, analyse le problème et le code connexe, décompose le travail en étapes, met en œuvre les changements, exécute la suite de tests complète et ouvre une pull request. Chaque pull request est soumise aux mêmes exigences d’approbation que le code écrit par des humains, y compris la réussite de la CI et la révision par les propriétaires du code. Kiro n’a pas de permissions de fusion et ne peut pas contourner les règles de protection des branches.

Les tâches qui conviennent le mieux à cette approche sont celles dont les critères d’acceptation sont clairs et la portée isolée. Les mises à jour de dépendances, les corrections de bogues bien reproduits et les améliorations de documentation sont toutes de bonnes options pour commencer. Les tâches qui exigent des décisions architecturales ou des refontes transversales sont mieux laissées aux humains. Lorsque Kiro rencontre une ambiguïté, il pose des questions de clarification plutôt que de deviner. Dans notre déploiement sur les dépôts Kani et CBMC, nous n’avons observé aucune régression introduite par le code généré par Kiro qui a été fusionné.

Nous avons commencé à utiliser Kiro en mode autonome sur le dépôt Kani au début de novembre 2025 et l’avons étendu à CBMC plus tard le même mois. Sur les deux dépôts, les chiffres montrent l’impact positif :

• Maintenance du code (29 %) : mises à jour de dépendances, mises à niveau de la chaîne d’outils, améliorations de la CI et refonte
• Améliorations de la documentation (4 %) : mises à jour de la documentation du projet et des instructions de compilation
• Corrections de bogues (36 %) : résolution de problèmes signalés, y compris des plantages, des résultats incorrects et des violations d’invariants
• Achèvement de fonctionnalités (26 %) : traitement de lacunes documentées dans des fonctionnalités prototypes

Le graphique suivant montre l’activité mensuelle des pull requests dans le dépôt CBMC. Pendant la majeure partie de 2025, le dépôt affichait en moyenne moins de 2 problèmes résolus par mois. En novembre, ce nombre est passé à 60. Bon nombre de ces pull requests sont encore en cours de révision : sur les 64 PR soumises par Kiro dans CBMC pour novembre, 16 ont été fusionnées, 47 restent ouvertes et 1 a été fermée parce que le problème sous-jacent avait été résolu par un autre changement, en date de septembre 2026. Chacune d’elles traite un problème ouvert documenté. Sur CBMC et Kani combinés, Kiro a soumis des pull requests traitant 87 problèmes uniques en novembre et décembre 2025. Au cours des 22 mois précédents (de janvier 2024 à octobre 2025), l’équipe avait traité 94 problèmes au total sur les deux dépôts.

Sur les 94 pull requests que Kiro a soumises dans CBMC et Kani en novembre et décembre 2025, en date de septembre 2026, 35 (37 %) ont été fusionnées, 56 (60 %) restent ouvertes et en révision, et 3 (3 %) ont été fermées parce que les problèmes sous-jacents avaient été résolus par d’autres changements. Parmi les PR fusionnées, certaines l’ont été telles que soumises, tandis que d’autres ont nécessité un raffinement interactif. L’arriéré de révision révèle un goulot d’étranglement clé : Kiro peut générer des PR plus vite que l’équipe ne peut les réviser. Il s’agissait de changements substantiels : la PR médiane touchait 5 fichiers et ~110 lignes, tandis que la plus grande touchait environ 1 000 fichiers. À raison de 2 à 3 heures d’effort de développement concentré par tâche, les 94 PR représentent environ 200 à 280 heures d’effort de mise en œuvre, sans compter le temps de révision et les PR qui pourraient finalement ne pas être fusionnées; comme de nombreuses tâches concernent des corrections de bogues ou l’achèvement de fonctionnalités plutôt que des mises à jour mécaniques, il vaut mieux considérer ce chiffre comme une borne inférieure.

Le changement de débit est tout aussi frappant : CBMC affichait en moyenne moins de 2 problèmes résolus par mois au cours des 22 mois précédant Kiro, alors que novembre 2025 a vu 60 problèmes résolus, soit une augmentation de plus de 30×. Presque toutes les 65 PR ouvertes en novembre (64) ont été soumises par Kiro, ce qui indique que la pointe reflète une capacité d’agent ajoutée plutôt qu’un effort de développement redirigé. Globalement, Kiro a généré du travail de mise en œuvre à environ 10× le débit historique de résolution de problèmes de l’équipe, bien que la valeur réalisée dépende de la capacité de révision et de raffinement. Les PR fusionnées continuent de n’introduire aucune régression, un signal qui repose maintenant sur une base beaucoup plus large : sur l’ensemble du déploiement (de novembre 2025 à septembre 2026), 183 pull requests générées par Kiro ont été fusionnées dans les deux dépôts. Les 56 PR encore ouvertes de la cohorte initiale reflètent le goulot d’étranglement de la révision mentionné ci-dessus plutôt que des préoccupations de qualité, et le bilan de zéro régression continuera d’être réévalué à mesure qu’elles franchissent la révision.

Le projet Kani maintient un sous-module Git charon afin d’obtenir une représentation intermédiaire des programmes Rust pour d’autres flux de travail de vérification. Contrairement aux autres sous-modules mis à jour automatiquement par Dependabot, les mises à jour de charon exigent des tests d’intégration, car les changements dans la couche de traduction peuvent affecter la capacité de Kani à modéliser correctement la sémantique de Rust. Une mise à jour manuelle prend généralement de 2 à 3 heures, couvrant la mise à jour du sous-module, la compilation et l’investigation des échecs de compilation, l’analyse des changements en amont, les tests de régression et l’investigation des échecs de tests. Plutôt que de dépenser de façon répétée du temps de développement sur ce travail, nous avons confié le processus à Kiro, qui le gère de manière autonome.

Le problème Kani #2236 était dans l’arriéré depuis plus de deux ans. Kani est un outil de vérification formelle à code source ouvert pour Rust, utilisé dans la CI de projets AWS critiques, dont Firecracker et s2n-quic, et il s’appuie sur CBMC. Un fuzzer avait signalé un plantage du compilateur Kani avec des étapes de reproduction claires, mais en trouver la cause première exigeait un changement de contexte important. Il s’agit d’un triage délibéré plutôt que de négligence : les problèmes qui bloquent les utilisateurs ou menacent la solidité sont corrigés immédiatement, tandis qu’un plantage trouvé par un fuzzer sans utilisateur affecté perd chaque fois le concours de priorisation; il exige le même changement de contexte coûteux qu’un bogue bloquant pour les utilisateurs, sans le même bénéfice. Après avoir ajouté l’étiquette kiro, Kiro a soumis la PR #4461 avec un correctif et un test de régression en deux heures et 22 minutes; le temps humain consacré a été de moins de cinq minutes. Comme le problème était ancien, nous avons demandé à Kiro de vérifier d’abord si le bogue existait encore ou, s’il était résolu, d’ajouter le cas de reproduction comme test de régression. Kiro a adapté son plan et produit une PR que nous avons fusionnée directement.

Kiro a également produit les PR #4445 et #4464, mettant à jour de façon incrémentale le sous-module Git charon de Kani. Avec pour seule instruction de faire de petits commits clairement décrits, Kiro a analysé les mises à jour disponibles, déterminé la séquence de mise à jour, généré les commits et ouvert les PR. Les développeurs révisent les changements et peuvent demander du travail avec /kiro fix pour des commentaires précis ou /kiro all pour tous les commentaires. Les commits incrémentaux et les descriptions claires permettent aux réviseurs de se concentrer sur l’exactitude sémantique plutôt que sur le travail mécanique de mise à jour.

La section précédente a donné le titre pour le problème Kani #2236 : deux ans en dormance, puis résolu avec moins de cinq minutes d’effort humain. Voici comment la collaboration entre l’humain et l’agent s’est réellement déroulée.

Il a suffi d’attacher l’étiquette kiro au problème. L’agent s’est mis au travail, analysant le problème et répondant avec un plan :

Étant donné l’âge du problème, il aurait très bien pu être corrigé incidemment par un autre changement. Nous avons répondu au plan de Kiro avec les directives suivantes :

Kiro a répondu avec un plan de tâche mis à jour, puis a produit la pull request que nous avons fusionnée sous le nom de PR Kani #4461, sans qu’aucun membre de l’équipe n’ait à changer de contexte.

Comprendre où Kiro a échoué était aussi important que ses réussites, car cela a façonné l’attribution du travail et les attentes en matière de révision.

Correctifs incorrects qui passent la CI. Dans la PR CBMC #8892, un test de régression utilisait --no-library tout en appelant memcpy, de sorte que le chemin de code déclencheur n’était jamais exercé. Le test passait avec ou sans le correctif. Nous l’avons remplacé par un test unitaire qui exerçait directement la fonction touchée. Leçon : la réussite de la CI est nécessaire mais non suffisante; les réviseurs doivent vérifier que les tests valident le correctif.

Correctifs architecturalement erronés. Certains correctifs traitaient les symptômes plutôt que les causes premières. Dans la PR #8703, une restructuration de 172 lignes a brisé les quantificateurs imbriqués; le bon correctif tenait en 9 lignes à l’emplacement d’origine. Ces cas exigent des réviseurs ayant des connaissances architecturales, et Kiro a aussi parfois reconstruit des fonctionnalités au lieu d’utiliser les utilitaires existants.

Échecs propres à une plateforme. Comme Kiro développe sur Linux, des problèmes de plateforme peuvent passer inaperçus. La PR #8894 utilisait des structures vides (struct S {}), valides en tant qu’extension GCC mais rejetées en mode MSVC. Le correctif consistait à ajouter une balise gcc-only, malgré un test existant qui démontrait déjà la garde de plateforme pertinente.

Violations de formatage et PR obsolètes. Presque toutes les PR présentaient des problèmes de formatage mineurs. Les PR non révisées accumulent aussi des conflits : la PR #7861 était 1 614 commits derrière develop, ce qui a exigé un rebasage non trivial. Une révision rapide est essentielle pour éviter que les coûts s’accumulent.

Les limites décrites ci-dessus étaient réelles, mais elles ne sont pas la fin de l’histoire. Chacune d’elles a été résolue sans qu’un développeur n’ouvre un éditeur ou un IDE. À l’aide de la CLI Kiro, les responsables démarrent une session kiro-cli chat sur la branche de la PR et guident les correctifs par la conversation. Le responsable apporte le jugement; l’agent apporte l’exécution. Ce flux de travail en deux phases (génération autonome, puis raffinement interactif) combine les forces des deux modes et maintient le coût total en temps bien en dessous de celui d’un développeur effectuant chaque tâche de bout en bout.

Pourquoi deux phases fonctionnent. L’agent autonome élimine le problème du démarrage à froid. Au moment de la révision, il y a du code fonctionnel, des tests qui passent et une description claire de l’approche. La CLI interactive élimine la latence des allers-retours asynchrones, résolvant les problèmes en minutes plutôt qu’en heures. Aucune des deux phases n’exige que le responsable écrive du code directement.

Impact qualitatif. Rahul Kumar, Senior Manager of Applied Science in the AWS Automated Reasoning Group: “Kiro has fundamentally changed how we approach technical debt. Previously, submodule updates would sit in our backlog for weeks because they required context-switching from feature work. Now we label the issue with kiro and it handles the entire workflow, update, test, document. In November alone, we merged 15 Kiro-generated PRs into Kani with zero regressions.”

En prenant en charge la maintenance courante, Kiro libère les développeurs pour qu’ils se concentrent sur les décisions architecturales, la conception d’algorithmes complexes, l’engagement communautaire et la recherche en vérification formelle.

Si vous voulez essayer cette approche sur votre propre projet à code source ouvert, suivez les étapes ici.

Pour les tâches complexes ou le raffinement interactif, utilisez la CLI Kiro sur la branche de la pull request pour guider le travail par la conversation, comme décrit dans la section « Boucler la boucle » ci-dessus.

Kiro Web est en disponibilité générale pour tous les utilisateurs payants de Kiro sur app.kiro.dev. Si vous êtes déjà abonné à Kiro, connectez-vous sur app.kiro.dev/agent et suivez les étapes ci-dessus.

En date de septembre 2026, Kiro a soumis plus de 400 pull requests dans les dépôts publics CBMC et Kani, dont 183 ont été fusionnées, traitant environ 150 problèmes uniques. Dans un dépôt de préproduction privé comptant plus de 430 problèmes signalés, il a produit plus de 360 pull requests supplémentaires qui sont révisées et intégrées en amont de façon incrémentale. Si vous maintenez un dépôt avec un arriéré de problèmes bien définis, cette approche vous permettra de démarrer en quelques minutes.