L'autoguérison corrige votre environnement. Votre agent de codage corrige le code.

L'agent est déjà dans votre workflow. La construction ratée est là où elle devient aveugle. Les agents de codage de l'IA sont passés de la nouveauté à l'outil quotidien. Dans Stack Overflow's 2025 Developer Survey, 84 % des développeurs ont déclaré utiliser ou planifier d'utiliser des outils d'IA dans leur processus de développement, en hausse par rapport à 76 % l'année précédente, et environ un développeur professionnel sur sept utilise maintenant des agents d'IA au travail chaque jour. Parmi les développeurs qui ont utilisé des agents au travail, environ 70% conviennent que les agents ont réduit le temps qu'ils consacrent à des tâches spécifiques. Il y a un endroit, cependant, où cet agent a encore tendance à sombrer : l'IC échoué. Le pipeline devient rouge, et votre agent (comme vous) se voit remettre un mur de sortie de log des travaux qu'il n'a pas écrits, couvrant les étapes qu'il n'a pas touché. Il doit reconstruire ce qui a réellement cassé avant qu'il puisse tout réparer. Cette reconstruction est la partie coûteuse, et c'est exactement la partie Latchkey est construit pour supprimer. Cette pièce parle d'une division du travail propre. L'auto-guérison de Latchkey répare les défaillances qui concernent votre environnement, pas votre code. Pour les échecs qui sont vraiment au sujet de votre code, Latchkey ne devine pas et patch en votre nom. Au lieu de cela, il remet à votre propre agent de codage un compte complet et structuré de l'échec sur le protocole de contexte de modèle, de sorte que votre agent peut corriger le bogue avec le contexte complet au lieu de commencer à partir d'un fichier journal. Deux sortes de construction rouge, et un seul d'entre eux est à vous de réparer Presque chaque construction échouée est l'une des deux choses. Soit l'environnement vous laisse tomber (un réseau flasque, un disque complet, un processus tué pour mémoire, un outil manquant, une configuration qui dérive), soit votre code est en fait faux (une erreur de compilation, un test défaillant, une affirmation cassée). Ces deux cas veulent un traitement opposé, et les congeler est la façon dont les équipes finissent par refaire des pipelines et espérer vert. L'auto-guérison de Latchkey s'occupe du premier cas. Lorsqu'un pas échoue sur un coureur géré par Latchkey, Latchkey détecte l'échec, diagnostique la cause et applique un correctif pendant que le travail est toujours en cours, puis réexécute l'échec. Il cible les défaillances transitoires et environnementales, les réseaux flasques, les disques complets, les morts de mémoire, les outils manquants et la dérive de l'environnement qui n'ont rien à voir avec votre logique d'application. Il est intégré dans chaque coureur, sans frais distincts. Pour les défaillances que les règles fixes ne reconnaissent pas, un agent d'IA sur le coureur enquête, applique un correctif d'un ensemble d'action contrôlée, limité, et le vérifie en réexécutant l'étape. Quand elle n'est pas confiante, elle ne fait rien, et l'échec originel reste. Le deuxième cas est important pour cette histoire. Latchkey ne tente un correctif que lorsqu'il a une infrastructure de haute confiance ou un signal d'environnement. De véritables défauts de votre code passent à travers inchangé, donc vos tests échouent honnêtement. L'auto-guérison n'est pas délibérément dans l'affaire de rendre un test raté vert. Un test qui attrape un vrai bug fait son travail, et Latchkey le laisse tranquille. Donc, quand l'auto-guérison se retire, il fait une déclaration: cela ressemble à votre code, pas à votre environnement. C'est le moment où la remise commence. Pourquoi un vrai échec est si cher à déboguer à partir d'un journal Si votre environnement est sain et votre code est cassé, l'horloge commence à déboguer, et le débogage est là où le temps d'ingénierie disparaît tranquillement. Un rapport de Undo avec Cambridge Judge Business School a estimé que les développeurs perdent 620 millions d'heures par an pour déboger les défaillances de logiciels, à un coût d'environ 61 milliards de dollars. Le même rapport a révélé que la reproduction d'un échec est la plus grande barrière à la fixation plus rapide, nommée par 41 % des répondants, avant de passer le test ou de faire la correction elle-même. C'est comme ça qu'un IC a échoué. Comme l'indique un compte de développeur, le pipeline vous dit quelque chose de cassé, mais pas quoi ou pourquoi, et vous êtes laissé « en train de passer à travers des grumes brutes à travers de multiples emplois, en répartissant mentalement les différences d'environnement entre local et IC, devinant si l'échec est flou ou réel ». Le problème est l'aumône