A Blitzy levantou $200M a um valuation de $1,4B para o que chamam de orquestração de agentes hiperescalada — construir um knowledge graph dinâmico de uma codebase enterprise, depois fazer deploy de milhares de agentes em paralelo contra essa representação. Os números chave: 66,5% em SWE-Bench Pro (a variante mais difícil, distinta do subconjunto SWE-Bench Verified em que a maioria dos labs benchmarka), suporte de codebase de 1 milhão a 100 milhões de linhas de código, e 100.000+ chamadas de modelo subjacentes por run nas APIs de Google, Anthropic e OpenAI. A plataforma reivindica dúzias de clientes enterprise Global 2000 em dez indústrias, embora nomes específicos não tenham sido divulgados. Arquiteturalmente isso é um afastamento significativo da categoria single-agent-CLI que domina o mindshare de builders atual — Cursor, Claude Code, Aider todos rodam um único agente fazendo raciocínio sequencial. A Blitzy faz orquestração em escala de frota com grounding KG.
A arquitetura técnica para flaggar: engenharia reversa de uma codebase existente em knowledge graph estruturado é a pré-condição para trabalho de agentes em escala de frota. Sem essa representação, agentes paralelos se pisam (mesmo arquivo editado duas vezes) e perdem contexto através da codebase. O KG deixa o orquestrador particionar trabalho — agente A cuida das mudanças relacionadas a auth, agente B cuida de billing, etc. — sem cada agente precisar da codebase inteira no seu contexto. As 100.000 chamadas de modelo por run são o cost-driver e o diferenciador: a maioria dos agentes de codagem em produção faz 50-200 chamadas por tarefa. 100k calls significa exploração paralela massiva, geração de candidatos, votação e verificação em vez de chain-of-thought sequencial. SWE-Bench Pro a 66,5% nessa abordagem é competitivo com o que Sonnet 4.5 + Claude Code atinge em SWE-Bench Verified (82% com parallel test-time compute), mas Pro é mais difícil então a comparação direta não é limpa. O que não é divulgado: como decomposição de tarefas funciona realmente (rules-based, learned, híbrida?), qual é a latência-por-completação (runs paralelos deveriam ser rápidos em wall-clock, mas 100k chamadas API significa custo real), modos de falha quando o KG está stale ou errado, e como o orquestrador lida com discordância entre agentes.
A leitura ecossistema: agentes de codagem enterprise estão se bifurcando em duas arquiteturas. A categoria single-agent-IDE (Cursor, Claude Code, Windsurf) otimiza para loops apertados com um developer no assento — iteração rápida, correções frequentes, custo baixo por tarefa. Blitzy e a classe Devin/Cognition otimizam para «nos dê uma spec, volte amanhã» — custo alto por tarefa, sem developer no loop, mas aplicável a refactors grandes e builds de feature que setups single-agent não conseguem realisticamente atacar em uma sentada. A faixa 1M-100M LOC que a Blitzy mira é o sweet spot enterprise — codebases grandes demais para uma única sessão de Cursor segurar em contexto, onde a abordagem KG-grounded tem justificativa arquitetural clara. A economia de 100k-API-calls implica um custo unitário nas centenas a milhares de dólares por run, o que só faz sentido para entregáveis substanciais, não edição interativa. Para builders avaliando plataformas de agentes, a pergunta vira se seu trabalho é «developer needs assistance» (single-agent) ou «specification needs implementation» (frota) — não são substitutos, são categorias diferentes.
Movimento prático: se você roda uma org de engineering classe-Global-2000 com codebases além de 1M LOC e trabalho recorrente de refactor grande, a Blitzy está no pool de eval agora. Peça evidência específica sobre o claim de accuracy do KG — um knowledge graph que misrepresent a codebase vai corromper silenciosamente decisões de agentes paralelos de formas que são caras de debugar post-hoc. Pressione-os em custo-por-completação em escala de codebase enterprise típica, taxa de erro em deploys de produção (não scores de benchmark), e a pergunta de determinismo da orquestração (dois runs do mesmo input produzem o mesmo patch, ou diferentes?). Para builders rodando codebases menores, o setup single-agent Cursor/Claude Code continua sendo a ferramenta certa — a arquitetura da Blitzy se paga só quando a vantagem do paralelismo supera o overhead de orquestração, o que só entra em jogo passada certa escala de codebase. SWE-Bench Pro 66,5% é interessante mas não sinal portável até que harnesses independentes reportem; esse é o número de uma empresa e a disciplina de eval-honesty diz olhe para replicação.