Les liens entre Amazon et Anthropic mis à l’épreuve par OpenAI alors qu’AWS Continuum s’étend

Les liens entre Amazon et Anthropic sont entrés dans une nouvelle phase, AWS ayant, selon certaines informations, connecté Continuum à Claude Code et OpenAI Codex, malgré la concurrence directe entre ces agents de programmation. Cette initiative place une couche de sécurité indépendante au sein d’outils capables de générer, modifier et exécuter du code. Elle teste également la capacité d’AWS à rester neutre vis-à-vis des modèles alors qu’Amazon entretient une relation commerciale étroite avec Anthropic.

La connexion à Codex signalée n’a pas bénéficié de la même documentation publique détaillée que la prise en charge par AWS de Claude Code et de son propre environnement Kiro. Les documents publiés par AWS décrivent clairement l’intégration de Claude Code, la validation d’exploits simulés et la prise en charge de plusieurs plateformes d’hébergement de code. Cette lacune en matière de vérification est importante, car l’affirmation stratégique plus large dépend du fonctionnement de Continuum dans des environnements d’agents concurrents.

Il ne s’agit pas d’un analyseur supplémentaire ajouté vers la fin d’un pipeline de développement. AWS veut que Continuum suive les vulnérabilités depuis leur découverte jusqu’à leur validation, leur priorisation et leur correction. Si cette approche fonctionne, les agents de programmation produiront des modifications tandis qu’un agent distinct déterminera si ces changements créent des risques exploitables.

AWS Continuum intègre la sécurité à la session de programmation

AWS déplace l’examen de sécurité d’un point de contrôle distinct vers l’espace de travail où un agent d’IA écrit et modifie le code.

AWS a présenté Continuum pour les vulnérabilités de code lors de son sommet de New York, le 17 juin 2026. Le service est entré en préversion limitée avec un flux de travail continu couvrant la découverte, la priorisation, la validation, l’atténuation et la correction.

L’entreprise présente Continuum comme indépendant des modèles. Cela signifie qu’il peut attribuer différentes tâches de sécurité à différents modèles de pointe et intégrer de nouveaux modèles à mesure qu’ils deviennent disponibles. Cette conception évite de lier l’ensemble du processus de sécurité à un seul fournisseur de modèles.

AWS a également intégré à la famille Continuum des capacités issues d’AWS Security Agent. Elles incluent l’analyse de code, les tests d’intrusion et la modélisation des menaces, qui transforme le code source ou les documents de conception en un modèle structuré d’attaques possibles.

L’intégration pour développeurs la plus clairement documentée est Claude Code. AWS indique que les développeurs peuvent lancer des tâches de sécurité depuis leur environnement de programmation au lieu de basculer vers une console de sécurité distincte. Ils peuvent créer des modèles de menaces, analyser des dépôts et traiter des résultats validés dans ce flux de travail.

Le plugin Claude Code fonctionne également avec les systèmes de contrôle de code source et les outils de collaboration. AWS a cité GitLab.com, GitLab autogéré, GitHub Enterprise, Bitbucket et Confluence parmi les intégrations prises en charge.

L’environnement Kiro d’AWS bénéficie d’un traitement similaire via un Kiro Power, une extension qui donne à un agent d’IA accès à des capacités spécialisées. Les deux intégrations rapprochent les retours de sécurité du moment où un agent propose une modification de code.

Le rapport d’août de VentureBeat étend cette stratégie à OpenAI Codex. Toutefois, les documents de lancement d’AWS publiés en juin et examinés pour cette analyse mentionnent Kiro et Claude Code, mais pas de plugin Codex comparable. AWS pourrait déployer la connexion Codex séparément ou via une couche d’intégration plus récente.

Cette distinction n’invalide pas l’évolution plus générale. Elle établit la frontière entre ce qu’AWS a publiquement documenté et ce qui a été rapporté. Les acheteurs en entreprise devraient demander la documentation produit avant de supposer une parité fonctionnelle entre les trois environnements de programmation.

Le changement immédiat reste substantiel. Continuum est conçu pour observer davantage qu’un fragment de code isolé. Il s’appuie sur l’infrastructure, les autorisations, la topologie réseau, la documentation, les communications et les priorités métier afin d’évaluer si un résultat représente un risque significatif.

Ce contexte élargi crée la tension centrale de l’article. AWS veut que les développeurs avancent rapidement avec l’agent de programmation de leur choix, tout en faisant d’AWS l’autorité de sécurité qui décide quels changements méritent d’être approuvés.

Pourquoi les liens entre Amazon et Anthropic ne produisent pas une pile exclusive

La surprise stratégique est qu’AWS bénéficie des succès de Claude Code, mais que Continuum gagne en valeur lorsqu’il prend aussi en charge les concurrents de Claude Code.

Amazon a investi massivement dans Anthropic et a fait de Claude un élément central de son offre d’IA générative. Anthropic s’appuie également sur l’infrastructure AWS, tandis que les modèles Claude restent des options importantes au sein d’Amazon Bedrock.

Cette relation donne à Amazon un intérêt direct dans la croissance d’Anthropic. Claude Code est devenu un point d’entrée important pour les développeurs utilisant Claude, en particulier pour les tâches à l’échelle d’un dépôt qui nécessitent planification, modification, tests et exécution répétée de commandes.

Un produit de sécurité AWS limité à Claude Code renforcerait ce partenariat. Il réduirait également le marché adressable de Continuum et rendrait le service moins utile aux entreprises exploitant des environnements de développement mixtes.

La plupart des grandes organisations ne standardisent pas tous leurs développeurs sur un seul agent de programmation. Les équipes évaluent les modèles selon le langage, le dépôt, le niveau de risque, la disponibilité et la politique interne. Certains développeurs font également passer une même modification entre plusieurs agents pour l’implémentation et la revue.

AWS a donc une incitation de plateforme qui diffère de l’incitation d’investissement d’Amazon. L’activité de plateforme bénéficie lorsque les charges de travail, le contexte de sécurité et les activités de correction transitent par AWS, quel que soit le modèle ayant écrit le code.

Cela explique pourquoi OpenAI Codex s’inscrit dans cette stratégie. Codex concurrence Claude Code au niveau de l’interface développeur, mais ses utilisateurs représentent une autre source de dépôts, de résultats et de décisions de sécurité pour Continuum.

Le résultat suit un schéma familier du cloud. Un fournisseur prend en charge des logiciels concurrents au-dessus de son infrastructure, car le choix des clients accroît la consommation des services de niveau inférieur du fournisseur.

Ce schéma ne rend pas la relation entre Amazon et Anthropic sans importance. Les recherches d’Anthropic sur la sécurité ont contribué à établir l’urgence de la découverte de vulnérabilités fondée sur le raisonnement. AWS a notamment cité des modèles de sécurité spécialisés, dont Claude Mythos, pour expliquer pourquoi les opérations de sécurité plus anciennes ne peuvent pas suivre le rythme.

Claude Mythos est présenté comme un modèle spécialisé dans le raisonnement en cybersécurité. Selon AWS, les modèles de cette catégorie peuvent trouver des vulnérabilités et raisonner sur des chemins d’attaque complexes plus rapidement que les équipes traditionnelles ne peuvent traiter le retard accumulé qui en résulte.

Cela crée une pression à double sens. De meilleurs modèles aident les défenseurs à localiser les défauts, mais les attaquants peuvent utiliser des capacités similaires pour les trouver et les exploiter. Chaque amélioration de la découverte automatisée augmente la valeur d’une validation et d’une correction rapides.

OpenAI poursuit la même opportunité via Codex Security. VentureBeat a indiqué que la bêta d’OpenAI avait analysé plus de 1,2 million de commits et fait remonter des milliers de résultats à différents niveaux de gravité. Ces chiffres restent des résultats communiqués par l’entreprise, plutôt qu’une comparaison indépendante.

Anthropic a également présenté Claude Code Security comme une alternative fondée sur le raisonnement à l’analyse statique orientée vers les motifs. Son lancement a suivi des recherches qui ont identifié des centaines de vulnérabilités de gravité élevée dans des projets open source établis, selon Anthropic.

AWS ne choisit pas entre ces récits de sécurité. L’entreprise positionne Continuum au-dessus d’eux. Les modèles de programmation peuvent rivaliser pour déterminer qui trouve ou corrige les failles les plus difficiles, tandis qu’AWS gère le contexte, la validation, les contrôles et le flux de travail d’entreprise.

La stratégie Amazon-Anthropic rencontre une couche de sécurité neutre vis-à-vis des modèles

Le mécanisme le plus important de Continuum n’est pas la découverte de vulnérabilités, mais la séparation entre la génération de code et le jugement de sécurité.

Les agents de programmation occupent une position inhabituelle dans le processus de développement. Ils peuvent lire des dépôts, invoquer des outils, modifier des fichiers, exécuter des tests, ouvrir des pull requests et parfois interagir avec des systèmes de déploiement.

Cet accès les rend productifs. Il fait également de leurs identifiants et de leurs autorisations d’exécution des cibles de sécurité.

VentureBeat a documenté plusieurs incidents impliquant des agents de programmation, dans lesquels les attaquants ont visé les identifiants ou les chemins d’exécution plutôt que les poids des modèles. Une entrée malveillante n’avait pas besoin de vaincre l’intelligence du modèle. Elle devait seulement manipuler la manière dont l’agent utilisait ses outils autorisés.

Une vulnérabilité Codex signalée impliquait le traitement non sécurisé d’un nom de branche Git conçu à cette fin. Des chercheurs ont montré comment cette valeur pouvait atteindre un script de configuration et exposer un jeton OAuth. OpenAI aurait classé le problème au plus haut niveau de priorité interne et déployé un correctif.

Claude Code a fait l’objet d’un examen distinct concernant le contenu de packages et le comportement de commande et de contrôle. Ces incidents avaient des causes techniques différentes, mais ils ont révélé le même problème architectural. Un agent peut devenir une surface d’attaque dès lors qu’il détient des identifiants et agit au-delà d’une fenêtre de chat passive.

Les exploits visant les agents de programmation remettent également en cause la surveillance traditionnelle des identités. Un jeton valide peut authentifier l’action d’un agent même lorsque la requête sous-jacente a été manipulée par du contenu de dépôt non fiable.

Continuum tente de traiter une autre partie de ce risque. Il évalue les vulnérabilités du code en utilisant le contexte environnemental et métier, puis valide les exploits soupçonnés dans un bac à sable isolé.

Un bac à sable est un environnement cloisonné dans lequel du code potentiellement dangereux peut s’exécuter sans recevoir les accès habituels à la production. AWS indique que Continuum utilise cet environnement pour produire des preuves reproductibles qu’une vulnérabilité signalée est exploitable.

Cette étape est importante, car les systèmes d’analyse de code génèrent souvent des résultats qui ne correspondent pas à des risques de production réellement atteignables. Un composant vulnérable pourrait ne jamais s’exécuter, accepter des entrées externes ou se trouver sur un chemin menant à des données sensibles.

Le processus de priorisation de Continuum détermine si un composant affecté est déployé, accessible et connecté à la production. Il évalue également l’effet potentiel sur l’entreprise avant de classer les travaux de correction.

Le système évalue ensuite les protections existantes, telles que les contrôles réseau, les politiques et les mécanismes de détection. Pour les résultats validés, il peut recommander un correctif de code, une modification de politique ou une modification du réseau.

AWS indique que les correctifs suggérés passent par le même mécanisme de validation que celui utilisé pour confirmer le problème initial. Le système peut également montrer l’impact attendu et une voie de retour en arrière lorsque ces informations sont disponibles.

Cette boucle donne à AWS une raison d’intégrer à la fois Claude Code et Codex. Le modèle qui écrit un correctif n’a pas besoin d’être la seule autorité chargée de déterminer si ce correctif est sûr.

Une équipe pourrait laisser Claude Code créer une fonctionnalité, demander à Continuum de tester le chemin d’attaque qui en résulte, puis utiliser un autre modèle lors de la correction. Le même processus peut s’appliquer lorsque Codex produit la modification initiale.

Cette architecture limite également la dépendance envers un seul fournisseur de modèles. Si un modèle spécialisé devient meilleur pour la construction d’exploits ou la revue de correctifs, AWS peut l’ajouter sans remplacer l’agent de programmation préféré du développeur.

Pour le partenariat entre Amazon et Anthropic, la neutralité vis-à-vis des modèles constitue à la fois un avantage et une contrainte. Claude peut apporter un raisonnement spécialisé, mais AWS conserve le contrôle de l’orchestration, des politiques, de l’historique d’audit et du contexte cloud environnant.

La promesse de sécurité dépend du contexte et du contrôle

Continuum échange une part de l’autonomie des développeurs contre un système de sécurité centralisé capable de voir davantage de contexte et, à terme, d’agir davantage.

AWS affirme que le modèle d’opérations de sécurité utilisé au cours de la dernière décennie est en train de prendre du retard. Ce modèle collecte de la télémétrie, la stocke, construit des requêtes et présente des alertes dans des tableaux de bord pour examen humain.

Continuum relie au contraire la télémétrie au contexte, au raisonnement et à l’action. La différence est importante, car un tableau de bord supplémentaire ne ferait qu’ajouter des résultats à une file déjà saturée.

Le service fonctionne selon quatre phases continues. D’abord, il absorbe les arriérés de vulnérabilités existants et effectue ses propres analyses. Ensuite, il classe les résultats selon leur exploitabilité technique et le contexte métier.

Troisièmement, Continuum tente de reproduire une exploitation dans un environnement isolé. Quatrièmement, il recommande ou applique des mesures correctives via des modifications du code, du réseau ou des politiques.

L’architecture de Continuum débute dans un mode d’apprentissage contrôlé par des humains. Les recommandations comprennent une explication du raisonnement du système, ce qui permet aux équipes d’examiner les décisions avant d’accorder une autorité plus large.

Les organisations peuvent ensuite faire passer certaines catégories de risques en mode d’application. Dans ce mode, Continuum peut appliquer des correctifs plus automatisés dans les limites définies par le client.

Cette conception par étapes répond à une préoccupation centrale des entreprises. Les responsables de la sécurité souhaitent rarement qu’un nouvel agent apporte, dès son premier jour, des modifications sans restriction à l’ensemble des systèmes de production.

L’auditabilité devient essentielle à mesure que l’autorité s’accroît. AWS affirme que chaque décision est explicable et chaque action auditable. L’entreprise indique également que les utilisateurs peuvent voir pourquoi Continuum a recommandé une action et ce qu’impliquerait un retour en arrière.

Il s’agit d’affirmations de l’entreprise, et l’aperçu limité fournit peu d’éléments publics sur les performances dans des environnements de production variés. Les acheteurs devraient examiner la qualité des explications, et pas seulement vérifier que l’interface en génère.

Une explication lisible peut toujours omettre une hypothèse critique. Une action auditable peut toujours reposer sur un contexte incomplet. Un plan de retour en arrière peut échouer lorsqu’une modification affecte des services distribués ou des données persistantes.

La qualité du contexte pose un autre problème. Continuum ne peut raisonner sur le code source, les autorisations, la topologie, les documents, les communications et les priorités que si ces données sont exactes et accessibles.

Les inventaires d’infrastructure dérivent. La documentation devient obsolète. Les graphes d’autorisations comportent des exceptions. Les priorités métier peuvent entrer en conflit entre équipes, en particulier durant les incidents.

Centraliser ces données peut améliorer les décisions de sécurité, mais cela accroît aussi la sensibilité du système qui les exploite. Les contrôles d’accès doivent empêcher qu’un dépôt ou une équipe expose des informations appartenant à une autre.

Les équipes de développement doivent également comprendre à quel moment le contenu d’un dépôt peut influencer l’agent de sécurité. Les modèles de menace, commentaires, documents et descriptions de tickets peuvent contenir du texte non fiable. Les systèmes d’agents doivent empêcher que ce texte modifie discrètement la politique de sécurité ou le comportement des outils.

Ces préoccupations ne constituent pas des arguments contre la sécurité agentique. Elles expliquent pourquoi l’application automatisée devrait suivre une validation mesurée plutôt qu’une confiance fondée sur le marketing.

Les équipes qui évaluent Continuum devraient comparer ses décisions aux tests d’intrusion existants et aux examens manuels. Elles devraient mesurer les résultats confirmés, les faux positifs, les problèmes manqués, la qualité des remédiations, la réussite des retours en arrière et le temps gagné lors du triage.

Une base de connaissances d’ingénierie utile peut aussi soutenir l’examen humain. Les équipes ont besoin de dossiers consultables reliant les résultats aux décisions d’architecture, aux responsables, aux incidents passés et aux risques acceptés.

Le véritable test consiste à déterminer si Continuum améliore ces décisions sans les dissimuler derrière une interface d’agent. Une remédiation plus rapide a une valeur limitée si les équipes ne peuvent pas reconstituer pourquoi une modification de production a eu lieu.

Claude Code, Codex et les scanners traditionnels restent en concurrence

AWS Continuum arrive sur un marché où les fournisseurs de modèles, les éditeurs de sécurité et les plateformes cloud cherchent tous à contrôler la même décision de remédiation.

Les outils traditionnels de test statique de sécurité des applications, communément appelés SAST, recherchent dans le code source des schémas risqués et des catégories de défauts connues. Ils fonctionnent sans exécuter l’application et s’intègrent aux pipelines de développement établis.

Les modèles de raisonnement abordent le problème différemment. Ils peuvent suivre le flux de données à travers les fichiers, inférer l’intention des développeurs, relier plusieurs faiblesses et déterminer si une séquence d’actions crée un chemin exploitable.

Anthropic et OpenAI ont tous deux soutenu que les scanners fondés sur le raisonnement peuvent détecter des vulnérabilités que les systèmes basés sur des motifs manquent. Leurs lancements ont accru la pression sur les fournisseurs établis de sécurité applicative pour qu’ils ajoutent une analyse contextuelle plus approfondie.

La comparaison ne raconte pas une simple histoire de remplacement. Les scanners traditionnels offrent des règles déterministes, des contrôles de politiques matures, une large prise en charge des langages et des rapports de conformité familiers. Leur comportement peut être plus facile à reproduire lors d’analyses répétées.

Les systèmes fondés sur des modèles peuvent examiner des relations plus ambiguës, mais leurs résultats peuvent varier. Ils nécessitent également une gestion attentive du code source propriétaire, des prompts, des outils d’exécution et des preuves d’exploitation générées.

Des tests indépendants ont déjà mis en évidence des limites. Des chercheurs de Checkmarx ont signalé que des vulnérabilités moyennement complexes échappaient parfois à Claude Code Security lors de leur évaluation. Ce résultat n’établit pas un classement universel, mais il remet en question l’idée selon laquelle le raisonnement éliminerait les angles morts des scanners.

La comparaison des scanners montre également pourquoi les entreprises conserveront plusieurs contrôles. Un agent de raisonnement peut compléter l’analyse déterministe, l’analyse des dépendances, les tests et l’examen manuel, plutôt que les remplacer immédiatement.

Continuum ajoute une autre couche concurrentielle, car il ne se contente pas d’analyser. Il associe les résultats au contexte de l’environnement AWS, puis gère le parcours vers la remédiation.

Cela peut mettre sous pression les fournisseurs indépendants de sécurité lorsque les clients exploitent déjà une grande partie de leur infrastructure sur AWS. Le fournisseur cloud peut accéder à des relations de configuration qu’un outil externe peut demander aux clients d’exporter ou de reconstituer.

Les fournisseurs indépendants conservent des avantages importants. Ils peuvent prendre en charge plusieurs clouds sans privilégier un environnement. Ils peuvent aussi fournir une évaluation neutre lorsqu’un fournisseur cloud évalue les risques au sein de ses propres services.

OpenAI et Anthropic font face à un choix connexe. Ils peuvent approfondir leurs produits de sécurité natifs, s’intégrer à des couches d’orchestration externes ou poursuivre les deux stratégies.

Claude Code Security offre à Anthropic une relation directe avec les développeurs et les équipes de sécurité. Une intégration avec Continuum étend la portée de Claude Code dans les entreprises, mais permet également à AWS de contrôler les politiques et l’historique des remédiations.

Codex Security crée la même tension pour OpenAI. L’intégration peut faciliter l’approbation de Codex dans les organisations centrées sur AWS. Elle peut aussi réduire le contrôle d’OpenAI sur le flux de travail de sécurité entourant son agent.

La position neutre d’AWS à l’égard des modèles ne fonctionne que si les clients lui font confiance pour traiter ces outils de manière cohérente. Des écarts de fonctionnalités entre Kiro, Claude Code et Codex affaibliraient cette promesse.

Le manque de détails publics autour de l’intégration Codex signalée mérite donc attention. Les acheteurs devraient vérifier si Codex prend en charge les mêmes fonctions de modélisation des menaces, d’analyse, de validation d’exploitation et de remédiation que celles documentées pour Claude Code.

Ils devraient également demander où chaque tâche s’exécute, quel modèle reçoit le contenu du dépôt, combien de temps les artefacts restent stockés et si les résultats améliorent les modèles d’un fournisseur.

Les liens entre Amazon et Anthropic rendent ces questions plus importantes. AWS doit démontrer que sa relation étroite avec une entreprise de modèles ne transforme pas la neutralité des modèles en simple argument de communication.

Trois signaux montreront si AWS peut gagner la confiance des développeurs

La prochaine phase dépend de la parité des intégrations, d’une validation indépendante et d’éléments montrant que les clients accorderont à Continuum une autorité significative.

Le premier signal est une documentation technique complète concernant la connexion OpenAI Codex signalée. AWS devrait identifier les environnements pris en charge, les actions disponibles, les autorisations requises, la couverture régionale et les différences avec Claude Code ou Kiro.

Une documentation équivalente renforcerait la thèse de la neutralité des modèles. Un connecteur Codex plus limité montrerait que Continuum fonctionne encore mieux au sein de l’orbite Amazon Anthropic.

Le deuxième signal est constitué de tests indépendants de la validation simulée. Les chercheurs en sécurité doivent comparer les preuves d’exploitation de Continuum à des tests d’intrusion manuels sur des applications réalistes.

De solides résultats incluraient des taux élevés de reproduction pour les résultats valides et une réduction mesurable des faux positifs. Les chercheurs devraient également tester si les tentatives d’exploitation générées introduisent des risques dans l’environnement isolé ou divulguent un contexte sensible.

De mauvais résultats ne rendraient pas l’architecture sans intérêt. Ils maintiendraient Continuum dans un rôle de conseil et ralentiraient le passage du mode d’apprentissage au mode d’application.

Le troisième signal réside dans le comportement des clients durant l’aperçu limité. AWS affirme avoir travaillé avec des organisations des services financiers, de l’automobile et de la technologie pour façonner le produit.

Des déploiements nommés, des résultats mesurés et des historiques d’exploitation plus longs auraient plus de poids que des démonstrations de lancement. L’indicateur le plus révélateur sera le niveau d’autorité de remédiation que les clients accordent réellement au service.

Les équipes qui limitent Continuum aux recommandations tirent toujours de la valeur de la priorisation et de la validation. Toutefois, ce comportement montrerait que la confiance n’a pas encore atteint la vision d’action automatisée d’AWS.

Le passage au mode d’application fournirait des preuves plus solides. Les acheteurs devraient tout de même examiner le périmètre autorisé, car l’automatisation de mises à jour de dépendances à faible risque diffère fortement de la modification d’une politique réseau ou du code de production.

Le lancement plus large de la sécurité des agents relie Continuum à AWS Context, DevOps Agent, Kiro, Transform et Bedrock AgentCore. Ensemble, ces services dessinent un cycle de vie logiciel de plus en plus géré par des agents.

Un agent peut écrire du code. Un autre peut évaluer l’état de préparation d’une version. Un autre peut moderniser des dépendances vieillissantes. Continuum peut évaluer les vulnérabilités et recommander des modifications à travers la pile.

Cette répartition du travail pourrait réduire la dépendance envers un unique modèle de codage. Elle pourrait aussi faire d’AWS le plan de contrôle reliant des agents d’entreprises qui, autrement, se livrent une concurrence intense.

Les développeurs devraient se poser une question pratique avant d’adopter cette vision : quel agent est autorisé à juger le travail d’un autre agent, et quelles preuves soutiennent cette autorité ?

Les responsables de la sécurité devraient définir la réponse au moyen d’autorisations, de données d’évaluation et de flux de travail réversibles. Ils ne devraient pas se fier au fait que chaque outil porte le nom d’un fournisseur familier.

Le partenariat entre Amazon et Anthropic donne à AWS accès à des modèles importants et à une plateforme de développement en forte croissance. La prise en charge d’OpenAI Codex montrerait qu’AWS souhaite jouer un rôle plus large que la distribution de Claude.

Surveillez la documentation, les tests d’exploitation indépendants et l’adoption du mode d’application au cours des prochains mois. Ces signaux révéleront si Continuum devient une couche de sécurité de confiance ou reste un aperçu ambitieux.

Si votre équipe utilise Claude Code, Codex ou Kiro, cartographiez dès maintenant chaque identifiant et chaque action de production accessibles à ces agents. Décidez ensuite à quel endroit une étape de validation indépendante doit interrompre le flux de travail. Cet exercice apporte une valeur immédiate, avant même que Continuum ne soit largement disponible.