Contexte technique
J'ai examiné les premiers retours sur Antigravity 3.5 Flash et j'ai repéré une tendance plutôt que du simple battage médiatique : le modèle est loué exactement là où les choses s'effondrent d'habitude rapidement, c'est-à-dire dans la planification architecturale. Si cela se confirme dans des tests plus larges, c'est un signal fort pour l'implémentation de l'IA : le modèle ne se contente pas de compléter des morceaux de code, il garde la structure du système à l'esprit.
D'après les données disponibles, le tableau n'est pas tout blanc ou tout noir. Google met en avant 3.5 Flash comme un modèle agentic rapide avec de solides résultats sur Terminal-Bench, MCP Atlas et diverses tâches d'utilisation d'outils. Toutefois, dans SWE-Bench Pro, il ne semble pas être le leader incontesté, et c'est normal : c'est une chose d'élaborer une piste de solution, c'en est une autre de remporter systématiquement des évaluations d'ingénierie logicielle strictes.
Et c'est là que cela devient intéressant. Dans les discussions, les utilisateurs vantent le modèle mais critiquent Tavily : une requête de recherche générale renvoie souvent des communiqués lisses au lieu de tests utilisateurs réels. J'ai souvent rencontré ce problème : si la couche de récupération (retrieval) rapporte un communiqué de presse au lieu de faits bruts, n'importe quel modèle intelligent aura l'air soit trop génial, soit complètement stupide.
Par ailleurs, les plaintes concernant les requêtes non anglaises ne m'ont pas surpris. C'est un vieux problème pour le RAG : en russe ou dans d'autres langues, la recherche souffre souvent d'un moins bon rappel (recall), d'un moins bon classement et attire facilement le bruit anglophone. Ensuite, les gens blâment le LLM, alors que le problème réside dans l'API de recherche.
Entreprise et automatisation
La conclusion pratique est simple : si Antigravity 3.5 Flash maintient vraiment si bien l'architecture, il mérite d'être étudié pour l'automatisation de l'IA, où l'agent doit planifier des chaînes d'actions plutôt que de simplement discuter. C'est particulièrement vrai dans les scénarios de copilot internes, où le coût d'une erreur structurelle est bien plus élevé qu'une erreur dans une seule ligne de code.
Mais tout le monde ne gagne pas ici. Les gagnants sont les équipes qui évaluent l'ensemble de la pile technologique : modèle, retrieval, reranking, langue de requête, et coût des tokens. Les perdants sont ceux qui placent un modèle à la mode au-dessus d'une recherche fragile et s'étonnent ensuite que leur RAG mente avec autant de confiance que de frais.
Chez Nahornyi AI Lab, nous résolvons précisément ces problèmes en pratique : nous ne choisissons pas un modèle sur la base d'une annonce séduisante, mais nous construisons une architecture de solutions d'IA fonctionnelle pour un processus spécifique. Si votre recherche génère déjà du bruit et que l'agent prend des décisions sur un mauvais contexte, analysons cette boucle et assemblons une intégration d'IA afin que le système vous fasse gagner du temps, et non exploser votre budget en tokens et en débogage.