ASTER : un harness d’agent open source qui réfute ses propres findings avant de les publier
⏱️ Temps de lecture estimé : 4 minutes
https://github.com/Zfinix/aster
📌 ASTER est un harness d’agent open source (Rust) dédié au travail logiciel, avec une première capacité mature : la revue de code vérification-d’abord. Il sépare la production de candidats de défauts d’une passe adverse qui tente de les réfuter — seuls les findings qu’un sceptique ne peut pas tuer atteignent votre PR.
L’insight central mérite d’être énoncé clairement : un modèle qui note sa propre première passe, c’est le bug qui part en production. ASTER refuse ce schéma. La revue y est traitée comme une vérification, pas comme une génération. Le pipeline se décompose en quatre étapes coût-étagées.
D’abord, Hypothesize : un modèle bon marché sur-produit des candidats de défauts à partir du diff seul. Chaque candidat doit porter un failure_scenario concret, sinon il est écarté avant de coûter quoi que ce soit. Ensuite Retrieve : on ne tire que l’évidence dont le scénario du candidat a besoin — hunk modifié, fenêtre source, symbole englobant et sa définition, références tirées d’un index local SQLite/FTS5. Pas de parcours complet du dépôt.
Puis Verify : un second appel modèle, prompté pour réfuter, tue les findings plausibles mais faux. Le vérifieur n’hérite jamais du raisonnement de la première passe. Un candidat ne survit que s’il rapporte une confiance au-dessus d’un seuil configurable (--min-confidence, défaut 0.5). Vous pouvez pointer ASTER_VERIFY_MODEL vers un modèle plus fort pour une vraie indépendance. Enfin Shape : déduplication et classement par sévérité × confiance, puis émission de findings canoniques prêts pour des commentaires inline, des tickets Linear, ou un agent de fix. L’effort coûteux ne se dépense que sur la vérification adverse de ce qui survit, jamais sur le diff entier.
ASTER est honnête sur ses limites, ce qui rassure. La doc précise que le seuil de confiance filtre la confiance auto-rapportée du vérifieur — une heuristique utile, pas une probabilité calibrée. La précision de bout en bout et le taux de faux positifs sont mesurés par l’éval documentée dans BENCHMARKS.md, et les claims de précision s’appuient sur ces chiffres, pas sur le seul gate.
Au-delà de la revue, le harness fédère d’autres capacités : aster chat (agent codebase qui explore, lit, cherche, rappelle la mémoire, édite sous politique), aster fix (applique les corrections dictées par la revue), aster sessions et aster memory (contexte durable, transcripts repris, mémoire de projet progressive), aster skills et définitions d’agents, et aster-mcp pour l’injection progressive d’outils MCP.
Côté éthique de l’agent, quatre modes de permission cadrent l’action : plan (explore, présente un plan, n’édite jamais), manual (approbation avant chaque édition), auto (applique ce qui passe le safety check, pause sur le risqué), edit (édite sans demander, le défaut). L’agent ne fait rien sans un cadre explicite.
ASTER est model-agnostic et self-host first. Tout endpoint compatible OpenAI passe : OpenRouter, Groq, OpenAI, un serveur llama.cpp local. Les fichiers locaux et SQLite/FTS5 sont la source du contexte — pas de control plane hébergé, pas de vector DB dans le cœur. Les clés API ne se lisent que depuis l’environnement ou aster login, jamais depuis le fichier de config. La revue se cible sur la branche courante, un range git, un diff stdin, ou une PR GitHub (--pr) avec publication en commentaires inline.
Mon avis est net. L’approche vérification-d’abord d’ASTER adresse le vrai défaut des revues IA : le faux positif plausible qui érode la confiance et finit ignoré. Séparer produire et réfuter, avec deux modèles et un prompt adverse, est l’architecture correcte pour ce problème. La réserve tient à la maturité : le projet est annoncé « early, building in the open », pré-release, à compiler depuis les sources (Rust ≥ 1.85). Le code review est la seule capacité pleinement mature ; le fix flow et les agents spécialisés sont en cours. Pour qui veut une revue de code IA sérieuse et auto-hébergeable, c’est l’une des fondations les mieux pensées du moment.
Points clés :
- 🎯 Pipeline 4 étapes : Hypothesize → Retrieve → Verify (réfuter) → Shape
- ⚔️ Deux modèles : un bon marché sur-produit, un indépendant réfute
- 📊 Confidence gate (
--min-confidence0.5) + précision mesurée dans BENCHMARKS - 🔍 Index local SQLite/FTS5 + ripgrep, zéro parcours complet de dépôt
- 🔌 Model-agnostic (OpenRouter, Groq, OpenAI, llama.cpp local), self-host
- 🛡️ 4 modes de permission : plan / manual / auto / edit
- 🧱 Capacités : review, chat, fix, sessions, memory, skills, MCP
- 📦 Rust, Apache-2.0, pré-release,
aster review --pr N --comment
Sources :
