Blitzy a levé 200 M$ à une valorisation de 1,4 Md$ pour ce qu'ils appellent l'orchestration d'agents hyperscalée — construire un knowledge graph dynamique d'une codebase enterprise, puis déployer des milliers d'agents en parallèle contre cette représentation. Les chiffres clés : 66,5 % sur SWE-Bench Pro (la variante plus dure, distincte du sous-ensemble SWE-Bench Verified sur lequel la plupart des labs benchmarkent), support de codebase de 1 million à 100 millions de lignes de code, et 100 000+ appels de modèle sous-jacents par run à travers les APIs Google, Anthropic et OpenAI. La plateforme claim des dizaines de clients enterprise Global 2000 dans dix industries, bien que les noms spécifiques n'aient pas été divulgués. Architecturalement, c'est un départ significatif de la catégorie single-agent-CLI qui domine le mindshare des builders actuels — Cursor, Claude Code, Aider font tous tourner un seul agent qui fait du raisonnement séquentiel. Blitzy fait de l'orchestration à l'échelle de flotte avec un grounding KG.
L'architecture technique à flagger : le reverse-engineering d'une codebase existante en knowledge graph structuré est la précondition pour du travail d'agents à l'échelle de flotte. Sans cette représentation, les agents parallèles se piétinent (même fichier édité deux fois) et perdent le contexte à travers la codebase. Le KG laisse l'orchestrateur partitionner le travail — agent A handle les changements liés à l'auth, agent B handle le billing, etc. — sans que chaque agent ait besoin de la codebase complète dans son contexte. Les 100 000 appels de modèle par run sont le cost-driver et le différentiateur : la plupart des agents codeurs en production font 50-200 appels par tâche. 100k calls veut dire exploration parallèle massive, génération de candidats, vote et vérification plutôt que chain-of-thought séquentiel. SWE-Bench Pro à 66,5 % sur cette approche est compétitif avec ce que Sonnet 4.5 + Claude Code atteint sur SWE-Bench Verified (82 % avec parallel test-time compute), mais Pro est plus dur donc la comparaison directe n'est pas propre. Ce qui n'est pas divulgué : comment la décomposition de tâches fonctionne réellement (rules-based, learned, hybride ?), quelle est la latence-par-complétion (les runs parallèles devraient être rapides en wall-clock, mais 100k appels API veut dire un vrai coût), les modes de failure quand le KG est stale ou faux, et comment l'orchestrateur handle le désaccord entre agents.
La lecture ecosystem : les agents codeurs enterprise se bifurquent en deux architectures. La catégorie single-agent-IDE (Cursor, Claude Code, Windsurf) optimise pour des boucles serrées avec un développeur dans le siège — itération rapide, corrections fréquentes, faible coût par tâche. Blitzy et la classe Devin/Cognition optimisent pour « donne-nous une spec, reviens demain » — coût par tâche élevé, pas de développeur dans la boucle, mais applicable aux gros refactors et builds de feature que les setups single-agent ne peuvent pas tackler réalistiquement en une session. La fourchette 1M-100M LOC que Blitzy cible est le sweet spot enterprise — codebases trop grandes pour qu'une seule session Cursor les tienne en contexte, où l'approche KG-grounded a une justification architecturale claire. L'économie 100k-API-call implique un coût unitaire dans les centaines à milliers de dollars par run, ce qui n'a de sens que pour des livrables substantiels, pas l'édition interactive. Pour les builders qui évaluent des plateformes d'agents, la question devient si ton travail est « developer needs assistance » (single-agent) ou « specification needs implementation » (flotte) — ce ne sont pas des substituts, c'est des catégories différentes.
Move pratique : si tu fais tourner une org engineering classe-Global-2000 avec des codebases passées 1M LOC et du travail récurrent de gros refactor, Blitzy est dans le pool d'eval maintenant. Demande des preuves spécifiques sur le claim d'accuracy du KG — un knowledge graph qui misrepresent la codebase va silencieusement corrompre les décisions d'agents parallèles d'une manière qui est chère à débugger post-hoc. Pin-les sur le coût-par-complétion à l'échelle d'une codebase enterprise typique, le taux d'erreur en déploiements production (pas les scores benchmark), et la question du déterminisme de l'orchestration (deux runs du même input produisent-ils le même patch, ou différents ?). Pour les builders qui font tourner des codebases plus petites, le setup Cursor/Claude Code single-agent reste le bon outil — l'architecture de Blitzy se rentabilise seulement quand l'avantage du parallélisme surpasse l'overhead d'orchestration, ce qui ne kick in qu'au-delà d'une certaine taille de codebase. SWE-Bench Pro 66,5 % est intéressant mais pas un signal portable jusqu'à ce que des harness indépendants le rapportent ; c'est le chiffre d'une compagnie et la discipline d'eval-honesty dit watch pour la réplication.