
Tech • IA • Robotique • Jeu
Qodo construit une couche de revue de code et de gouvernance par IA qui injecte la connaissance de l’organisation dans les agents de codage, vérifie les changements à l’échelle du système selon le risque, et vise à réduire la fréquence des interventions humaines avant la mise en production.
Qodo, dirigée par le PDG Itamar Friedman, présente son produit comme un compagnon de Codex et d’agents de codage similaires. Le système collecte du contexte d’ingénierie au-delà du seul code, l’injecte dans la génération et la revue, et aide à produire dès le départ des pull requests plus propres. À plus long terme, l’objectif est une couche de gouvernance qui cartographie les systèmes logiciels et suit leur dérive dans le temps.
L’entreprise distingue l’intelligence de la sagesse. Le code seul capture l’implémentation, mais pas l’expérience accumulée d’une organisation d’ingénierie: ce qui a déjà échoué, quelles dépendances sont fragiles, où se situe le risque opérationnel, et quels patterns sont sûrs à grande échelle. Cette expérience, souvent détenue sous forme de savoir tribal, est traitée comme une entrée clé pour la génération comme pour la revue du code.
Un problème récurrent en développement logiciel est qu’un changement peut paraître correct isolément tout en provoquant une panne en aval ailleurs. Friedman a cité des clients servant des millions de petites et moyennes entreprises, où des systèmes flexibles peuvent exposer des changements liés aux bases de données à un risque disproportionné. Dans ces cas, une modification localement cohérente peut malgré tout déclencher une panne majeure à l’échelle du système, un type de problème difficile à détecter sans cartographie globale, pour les humains comme pour les agents.
L’entreprise décrit une progression de la prompt engineering en 2023, à la flow engineering en 2024, puis aujourd’hui à la swarm engineering. Le prompting convenait aux premiers flux de questions-réponses, tandis que la flow engineering modélisait les étapes suivies par un développeur sur une tâche. La swarm engineering va plus loin en assignant à plusieurs agents des objectifs, outils, garde-fous et politiques distincts, au lieu de les laisser créer eux-mêmes récursivement des sous-agents et des workflows.
Friedman estime que les systèmes d’agents autonomes en sont encore à leurs débuts et peuvent devenir coûteux s’ils ne sont pas contraints. Pour des produits qui doivent inspirer confiance, les résultats doivent être ancrés dans des preuves, avec des systèmes de revue conçus pour montrer pourquoi une conclusion a été atteinte. Cet ancrage est particulièrement important lorsque les agents de codage et les agents de revue adversariale ne sont pas d’accord.
Une métrique pratique pour la revue assistée par IA est la fréquence à laquelle un développeur humain doit intervenir. L’objectif est que les agents de codage et de revue règlent la plupart des problèmes pendant l’écriture du code, au lieu de faire remonter de longues listes d’observations seulement sur la page de pull request. Selon ce critère, un système de revue efficace réduit le nombre de sollicitations nécessaires pour obtenir une pull request de haute qualité.
Selon l’entreprise, des agents raisonnables disposant des mêmes informations devraient converger vers la même réponse. Si ce n’est pas le cas, la cause probable est un contexte différent. Un relecteur humain reste utile en cas de conflit entre agents, mais le processus s’améliore si chaque jugement s’appuie sur des preuves partagées et une connaissance du système plutôt que sur des extraits de code isolés.
Même si les agents de codage, les agents de revue, les développeurs et les relecteurs sont tous d’accord, des erreurs peuvent encore atteindre la production. La réponse proposée est l’apprentissage continu: les incidents, bugs et échecs après déploiement doivent être capturés et enregistrés dans une base de connaissances, ou “base de sagesse”, afin d’éviter de répéter les mêmes erreurs. Friedman affirme que l’IA rend cette codification des leçons apprises plus faisable qu’auparavant.
Un exemple concernait une grande institution financière d’Asie du Sud-Est avec des centaines de dépôts et de nombreux microservices. Dans de tels environnements, des connaissances critiques sur ce qui fonctionne en toute sécurité à grande échelle peuvent ne résider que chez quelques développeurs seniors, dont certains sont déjà partis. L’approche de Qodo inclut l’analyse de plusieurs années d’échanges dans des outils comme GitHub, GitLab, Bitbucket, Slack et Teams pour reconstruire ce savoir et relier les changements de services à leurs effets en aval, y compris des flux de données non évidents.
À mesure que les modèles s’améliorent, l’entreprise s’attend à ce que les équipes logicielles redéfinissent ce qui constitue une tâche. Au lieu de traiter la pull request comme unité principale de travail, les équipes pourraient passer à des capacités ou fonctionnalités de bout en bout couvrant plusieurs pull requests et dépôts. Qodo indique prévoir le lancement de work package triage, une fonctionnalité conçue pour montrer comment plusieurs pull requests se rattachent à une tâche plus large et pour les revoir dans leur ensemble.
Le pari central est que la revue de code par IA portera de moins en moins sur la vérification de la syntaxe et du style, et de plus en plus sur l’encodage de la mémoire institutionnelle, du contexte système et du risque opérationnel. Si cela fonctionne, la supervision humaine passera d’une revue ligne par ligne à la définition des politiques, au traitement des exceptions et à l’apprentissage continu.
Poser une question