Blitzy levantó $200M a una valuación de $1,4B para lo que llaman orquestación de agentes hiperescalada — construir un knowledge graph dinámico de una codebase enterprise, luego desplegar miles de agentes en paralelo contra esa representación. Los números clave: 66,5% en SWE-Bench Pro (la variante más dura, distinta del subconjunto SWE-Bench Verified sobre el que la mayoría de labs benchmarkean), soporte de codebase de 1 millón a 100 millones de líneas de código, y 100.000+ llamadas a modelo subyacentes por run a través de APIs de Google, Anthropic y OpenAI. La plataforma reclama docenas de clientes enterprise Global 2000 en diez industrias, aunque nombres específicos no fueron divulgados. Arquitectónicamente esto es un alejamiento significativo de la categoría single-agent-CLI que domina el mindshare de builders actual — Cursor, Claude Code, Aider todos corren un solo agente haciendo razonamiento secuencial. Blitzy hace orquestación a escala de flota con grounding KG.
La arquitectura técnica a flaggear: ingeniería inversa de una codebase existente en knowledge graph estructurado es la precondición para trabajo de agentes a escala de flota. Sin esa representación, agentes paralelos se pisan (mismo archivo editado dos veces) y pierden contexto a través de la codebase. El KG deja al orquestador particionar trabajo — agente A maneja cambios relacionados a auth, agente B maneja billing, etc. — sin que cada agente necesite la codebase completa en su contexto. Las 100.000 llamadas a modelo por run son el cost-driver y el diferenciador: la mayoría de agentes de codeo en producción hacen 50-200 llamadas por tarea. 100k calls significa exploración paralela masiva, generación de candidatos, votación y verificación en lugar de chain-of-thought secuencial. SWE-Bench Pro a 66,5% en este enfoque es competitivo con lo que Sonnet 4.5 + Claude Code logra en SWE-Bench Verified (82% con parallel test-time compute), pero Pro es más dura así que la comparación directa no es limpia. Lo que no se divulga: cómo funciona realmente la descomposición de tareas (rules-based, learned, híbrida?), qué es la latencia-por-completación (runs paralelos deberían ser rápidos en wall-clock, pero 100k llamadas API significa costo real), modos de fallo cuando el KG está stale o equivocado, y cómo el orquestador maneja el desacuerdo entre agentes.
La lectura ecosystem: los agentes de codeo enterprise se están bifurcando en dos arquitecturas. La categoría single-agent-IDE (Cursor, Claude Code, Windsurf) optimiza para loops apretados con un developer en el asiento — iteración rápida, correcciones frecuentes, costo bajo por tarea. Blitzy y la clase Devin/Cognition optimizan para «danos una spec, vuelve mañana» — costo alto por tarea, sin developer en el loop, pero aplicable a refactors grandes y builds de feature que setups single-agent no pueden realísticamente tacklear en una sentada. El rango 1M-100M LOC que Blitzy apunta es el sweet spot enterprise — codebases demasiado grandes para que una sola sesión de Cursor las tenga en contexto, donde el enfoque KG-grounded tiene justificación arquitectónica clara. La economía de 100k-API-calls implica un costo unitario en los cientos a miles de dólares por run, lo que solo tiene sentido para entregables sustantivos, no edición interactiva. Para builders evaluando plataformas de agentes, la pregunta se vuelve si tu trabajo es «developer needs assistance» (single-agent) o «specification needs implementation» (flota) — no son sustitutos, son categorías diferentes.
Movida práctica: si corrés una org de engineering clase-Global-2000 con codebases pasadas 1M LOC y trabajo recurrente de refactor grande, Blitzy está en el pool de eval ahora. Pedí evidencia específica sobre el claim de accuracy del KG — un knowledge graph que misrepresent la codebase va a corromper silenciosamente decisiones de agentes paralelos en formas que son caras de debuggear post-hoc. Pinneálos en costo-por-completación a escala de codebase enterprise típica, tasa de error en deploys de producción (no scores benchmark), y la pregunta de determinismo de la orquestación (dos runs del mismo input producen el mismo patch, o diferentes?). Para builders corriendo codebases más chicas, el setup single-agent Cursor/Claude Code sigue siendo la herramienta correcta — la arquitectura de Blitzy se paga sola solo cuando la ventaja de paralelismo supera el overhead de orquestación, lo que solo entra en juego pasada cierta talla de codebase. SWE-Bench Pro 66,5% es interesante pero no señal portable hasta que harnesses independientes lo reporten; este es el número de una compañía y la disciplina de eval-honesty dice mirá para la replicación.