Comment Elastra transforme les changements de repos en contexte utile pour des fixes plus rapides et plus sûrs

La plupart des agents de code échouent pour la même raison : ils savent trop peu de choses sur le codebase au moment où ils doivent agir. Le problème n'est que rarement la qualité brute du modèle. C'est la qualité du contexte.

Elastra traite le contexte comme un système gouverné. Cela signifie que la fraîcheur, le périmètre et la sélection des preuves sont des sujets explicites au lieu d'hypothèses cachées. La plateforme n'essaie pas de faire entrer des repos entiers dans des prompts. Elle essaie d'assembler la plus petite portion utile de l'état du système.

L'enjeu n'est pas seulement d'avoir des skills. Les skills sont des primitives d'exécution ; le useful context est ce qui les amène à viser la bonne preuve et le bon changement.

Cette portion doit répondre à une question pratique : qu'est-ce qui a changé, de quoi cela dépend-il et quelles preuves soutiennent la prochaine action ? Si la réponse est faible, le fix sera faible. Si la réponse est obsolète, le fix sera risqué.

Le contexte ne reste utile que s'il suit le repo au fur et à mesure qu'il évolue. Elastra détecte les changements dans les repos connectés et met à jour la connaissance indexée pour que la prochaine récupération reflète le code actuel, pas celui de la semaine dernière.

C'est important parce qu'un contexte obsolète crée une fausse confiance. Un fichier peut avoir bougé, un symbole peut avoir été renommé, une dépendance peut avoir changé, ou un fix peut déjà avoir été livré sur la branche principale. Sans détection fraîche des changements, un agent peut perdre du temps à raisonner sur une version du système qui n'existe plus.

C'est là que les signaux de changement deviennent opérationnels. Ils permettent à Elastra de prioriser ce qui doit être réindexé, ce qui doit mettre à jour le graphe, et ce qui doit être présenté en premier lorsqu'une tâche arrive dans le workspace.

Un bug fix est rarement local à un seul fichier. Une fonction modifiée peut affecter les callers, les tests, les configs, les utilitaires partagés et les chemins de release. Le text retrieval peut trouver le fichier, mais les graphes expliquent le blast radius.

C'est pourquoi l'analyse en graphes est une partie centrale du contexte utile dans Elastra. Les appels, les dépendances, les modules, les chaînes d'impact et les symboles liés permettent de raisonner sur ce qu'il faut vérifier avant qu'un patch soit sûr.

Dans les workflows de fix, les graphes font deux choses particulièrement bien. Ils aident les agents à ne pas manquer les dépendances cachées et ils les aident à arrêter de collecter du contexte dès que la structure pertinente est couverte. Les deux réduisent le travail perdu.

Le retrieval sémantique existe parce que le matching exact par mots-clés est trop fragile pour le travail d'ingénierie réel. Deux fichiers peuvent décrire le même concept avec des noms différents, des abstractions différentes ou des couches différentes de la stack. Les embeddings donnent au système un moyen de comparer le sens, pas seulement la forme.

Dans Elastra, les embeddings ne sont pas la réponse à eux seuls. Ils constituent la base de ranking qui rend la recherche sémantique pratique dans les docs, le code et les chunks de connaissance. La couche de retrieval réduit ensuite l'espace de recherche vers les preuves les plus susceptibles d'aider la tâche.

C'est important parce que l'agent ne doit pas commencer par tout lire. Il doit commencer par lire les quelques éléments les plus pertinents, puis utiliser les signaux de graphe et de changement pour affiner la vue si la tâche est un fix ou une question d'architecture.

Le vrai test d'un système de contexte est de savoir s'il aide l'agent à agir avec moins d'angles morts. Elastra est conçu pour que l'agent puisse passer de la découverte à l'action sans porter plus d'information que nécessaire.

Ce chemin ressemble généralement à ceci : détecter le changement, récupérer les correspondances sémantiques les plus pertinentes, élargir avec les relations du graphe là où le fix peut se propager, puis s'arrêter dès que la preuve est suffisante.

C'est pourquoi un contexte utile n'est pas le plus grand prompt possible. C'est le plus petit prompt qui rend encore la décision suivante défendable. En pratique, c'est ce qui maintient les fixes plus rapides, les reviews plus propres et les coûts de retrieval sous contrôle.