Concepts¶
Trois idées suffisent à comprendre pourquoi AIM est construit ainsi. Elles sont courtes, et les lire évite de se battre contre le système plus tard.
-
Pourquoi l'extraction produit des objets typés et sourcés plutôt que du résumé.
-
Pourquoi il faut à la fois un pack statique et une recherche à la demande.
-
La seule hiérarchie de confiance que le système impose, et pourquoi elle suffit.
Le problème, formulé précisément¶
Un développeur qui arrive chez un client passe des semaines à apprendre des choses qui ne sont écrites nulle part au même endroit : où va tel type de code, quelle commande lance vraiment les tests, quelle règle non écrite fait recaler une pull request, quel piège a déjà coûté une nuit à quelqu'un.
Un agent de code, lui, n'apprend jamais. À chaque session, il repart de zéro et produit du travail plausible mais non conforme — la pire catégorie d'erreur, parce qu'elle passe la compilation et échoue en revue.
AIM existe pour supprimer cet écart : rendre disponible, au moment où l'agent écrit, ce qu'un collègue expérimenté lui aurait dit.
Le postulat de curation¶
AIM part d'une hypothèse forte et assumée : tu ne lui donnes que ce qui est pertinent et à jour.
Le système ne cherche pas à trier mille pages pour en garder douze. Il fait confiance à ta curation et consacre son budget d'inférence à extraire finement ce que tu lui confies. C'est ce qui lui permet d'être précis là où un système qui avalerait tout serait noyé.
Conséquence pratique : quand un pack devient bruyant, la réponse n'est presque jamais « améliorer l'extraction », c'est retirer une source.