Traiter de manière responsable le code généré par des agents : le cadre de Vercel

(vercel.com)

11 points par GN⁺ 26 일 전 | Aucun commentaire pour le moment. | Partager sur WhatsApp

Les agents de codage génèrent du code à une vitesse sans précédent, mais, utilisés sans discernement rigoureux, ils deviennent un moyen extrêmement efficace de déployer en production des hypothèses erronées telles quelles
Le code généré par des agents peut inclure une description de PR, passer l’analyse statique et même offrir une couverture de tests, au point de sembler avoir été écrit par un ingénieur expérimenté ; pourtant, il ne reflète en rien les schémas de trafic, les modes de panne ou les contraintes d’infrastructure d’un véritable environnement de production
Il existe une différence fondamentale entre mettre à profit (leveraging) l’IA et s’y reposer (relying) ; la véritable mise à profit consiste à comprendre pleinement le fonctionnement et les risques des sorties de l’agent, et à en assumer la responsabilité
Trois principes permettent de construire un environnement sûr tout en laissant les agents agir avec un haut degré d’autonomie : déploiements auto-pilotés, validation continue et garde-fous exécutables
L’époque n’est plus à l’ingénieur qui génère le plus de code, mais à celui qui conserve un jugement lucide sur ce qu’il faut déployer

Le problème : un CI au vert n’est plus une preuve de sécurité

Passer la CI reflète seulement la capacité de l’agent à convaincre le pipeline, et n’a rien à voir avec la sécurité réelle de l’infrastructure
- Il est possible de déployer une requête qui passe les tests mais effectue un scan complet de lignes en production
- Une logique de retry en apparence saine peut provoquer un Thundering Herd sur des services en aval
- Un cache sans TTL peut conduire Redis à l’asphyxie en silence
Les agents ne savent pas si une instance Redis est proche de la saturation, si une base de données a un hardcoding propre à une région spécifique, ou si le rollout d’un feature flag modifie le profil de charge des systèmes en aval
L’écart entre « cette PR semble correcte » et « cette PR peut être déployée en toute sécurité » a toujours existé, et les agents ne font que l’agrandir

S’y reposer (Relying) : considérer qu’une fois l’agent passé par l’écriture et les tests, le déploiement est prêt
- L’auteur ne construit pas de modèle mental du changement
- On obtient de gigantesques PR remplies d’hypothèses cachées, que ni l’auteur ni le relecteur ne comprennent réellement
Mettre à profit (Leveraging) : utiliser l’agent pour itérer rapidement tout en gardant l’entière responsabilité du résultat
- Comprendre précisément comment le code se comporte sous charge
- Comprendre les risques associés et être prêt à les assumer
Apposer son nom sur une PR signifie : « je l’ai lue et je comprends ce qu’elle fait » ; c’est le point de référence du processus d’ingénierie

Test simple : « Serais-je à l’aise d’assumer un incident de production lié à cette PR ? »
Trois questions à se poser avant de soumettre une PR
- Que fait ce code ? Comment se comportera-t-il après le rollout ?
- Quel impact négatif peut-il avoir sur la production ou sur les clients ?
- Suis-je à l’aise à l’idée d’assumer un incident lié à ce code ?
Si la réponse est « oui », alors vous mettez l’IA à profit et vous pouvez déployer ; si c’est « non », il reste du travail

Déploiements auto-pilotés (Self-driving deployments) : chaque changement est déployé progressivement via un pipeline à garde d’entrée, et le déploiement canari effectue un rollback automatique en cas de dégradation des performances
- On ne dépend pas d’ingénieurs rivés à des dashboards
- En cas de problème, l’impact est isolé sur une partie du trafic plutôt que sur l’ensemble
Validation continue (Continuous validation) : on teste en permanence l’infrastructure elle-même, et pas seulement au moment du déploiement
- Des tests de charge, expériences de chaos et exercices de reprise après sinistre sont exécutés en continu
- C’est pourquoi le basculement de base de données répété par Vercel en production l’été dernier n’a eu aucun impact client lors de la panne réelle d’Azure
Garde-fous exécutables (Executable guardrails) : encoder le savoir opérationnel dans des outils exécutables plutôt que dans des documents
- La compétence safe-rollout n’est pas une page Notion expliquant comment fonctionnent les feature flags, mais un outil qui relie les flags, génère un plan de rollout avec conditions de rollback et précise comment valider le comportement attendu
- Lorsque les garde-fous sont exécutables, les agents peuvent les suivre de manière autonome et les humains n’ont pas besoin de les mémoriser

Renforcer les garde-fous d’infrastructure partagés en appliquant une validation à l’exécution à chaque étape du pipeline de déploiement
Renforcer les vérifications statiques au stade de la PR, en particulier autour des feature flags
Introduire des tests end-to-end avec mise en miroir de la production dans l’environnement de staging
Faire tourner en production des agents en lecture seule qui valident en continu les invariants du système, et utiliser des agents spécialisés pour auditer les hypothèses des agents génératifs
Introduire des métriques telles que le ratio d’échappement des défauts par rapport aux commits défectueux afin de détecter une hausse du risque à l’échelle de la plateforme

L’implémentation est devenue abondante ; la ressource rare, désormais, est le jugement sur ce qui peut être déployé en toute sécurité
L’époque où un code de mauvaise qualité se voyait immédiatement est révolue ; les outils d’IA vont gagner en puissance, les diff vont grossir et la tentation de faire aveuglément confiance aux sorties va augmenter
L’objectif n’est pas un monde où chaque changement exige une rigueur extraordinaire, mais un monde où l’infrastructure elle-même est rigoureuse — un environnement où déployer rapidement est, par défaut, sûr