A semana em que a capacidade do modelo deixou de ser o gargalo — e o ambiente, o gateway e a capacidade de inferência viraram o produto que o CTO precisa precificar.
Quarenta e seis por cento.
É a taxa em que revisores humanos rejeitam os fixes de código gerados por Copilot, Devin, Cursor e Claude. Em 932 mil pull requests analisados. No mundo real.
Esta é a Edition da ai|expert — edição quinze. A semana em que a capacidade do modelo deixou de ser o gargalo, e o ambiente, o gateway e o silício viraram o produto que o CTO precisa aprender a precificar.
Um paper publicado essa semana no arXiv colocou um número no que muita gente suspeitava, mas preferia não medir.
O conjunto de dados se chama AIDev: 932.791 pull requests agenticos, em 116.211 repositórios, com 72.189 desenvolvedores envolvidos. É o maior dataset de comportamento de agentes de código publicado até hoje. [ref: 46-of-ai-generated-code-fixes-]
E o número central: 46,41% dos fixes propostos pelos agentes foram rejeitados por revisores humanos.
Os pesquisadores analisaram 306 PRs não mergeados de GitHub Copilot, Devin, Cursor e Claude Code, e catalogaram 14 razões de rejeição dentro de quatro categorias: implementação incorreta, falha em CI pipeline, incapacidade do agente, e baixa prioridade da fix. Esse é o fault model que faltava para debugar um pipeline agentico de código.
O que torna o dado ainda mais revelador é o que acontece quando você separa por agente.
Copilot e Codex passam em CI com taxas acima de 93% e 94%, respectivamente — em 61.837 runs de GitHub Actions analisados em 2.355 repositórios. Por qualquer métrica de CI, eles estão funcionando. Mas o Copilot tem o menor índice de merge entre todos os agentes nos PRs de fix: 42,4%.
E a contradição se aprofunda. Copilot gera uma média de 2,56 comentários por PR. Todos os outros agentes ficam abaixo de 1,0 comentário por PR. O Copilot cria mais discussão, passa mais em CI, e ainda assim é o que menos vira código em produção.
Isso tem uma leitura clara: volume alto com baixo sinal-para-ruído é pior do que volume baixo com alta precisão. Você está pagando em compute de CI, em tokens, e — o custo invisível — em atenção cognitiva dos revisores, por artefatos que nunca vão a lugar nenhum.
Tem um detalhe operacional sobre o Devin que merece destaque isolado.
O Devin fechou automaticamente 32,1% dos próprios PRs após detectar inatividade do revisor — postando o comentário "Closing due to inactivity" por conta própria. Merge rate: 42,9%. Ligeiramente acima do Copilot. O Cursor, por outro lado, atraiu a maior proporção de sentimento negativo nos comentários dos revisores — o único agente com maioria de reações negativas no dataset.
A correlação mais importante do dataset: há correlação negativa entre frequência de contribuição agentica e taxa de sucesso em workflow. Quanto mais volume o agente gera, mais a confiabilidade do pipeline como um todo se deteriora.
Isso não é acidente. É a consequência direta de tratar geração de pull request como geração aberta, sem constraints definidos. O paper identifica três pontos de controle que reduzem rejeição: fornecer approach hints explícitos antes da geração, delimitar constraints e padrões proibidos, e enforcer validação de CI sem introduzir breaking changes.
Isso exige uma camada de guidance entre o issue tracker e o context window do agente. Um filtro de tarefas de baixa prioridade. Um harness de validação pré-criação de PR. Sem isso, você está gerando volume para o seu time de review absorver — não código para shippar.
Agora leva esse dado de 46% para o EvoArena, e o problema fica ainda mais denso. [ref: evoarena-benchmarks-llm-agent-]
Um grupo da National University of Singapore, com Salesforce AI Research e MIT, publicou o primeiro benchmark que modela drift de ambiente da forma que o mundo real funciona: mudanças progressivas, versionadas, encadeadas. Não um snapshot estático. Uma sequência de atualizações onde o agente precisa manter o que ainda é válido e descartar o que mudou.
Três sub-benchmarks: Terminal-Bench-Evo para workflows de CLI em evolução, SWE-Chain-Evo para codebases em mudança, e PersonaMem-Evo para preferências de usuário que derivam no tempo.
O resultado: agentes atuais acertam em média 39,6% das tarefas em ambientes evolutivos. A falha modal tem um nome técnico: state collapse.
State collapse: o agente mantém uma única representação de estado mais recente. Quando uma regra de permissão ou schema de API é atualizado, a nova versão sobrescreve a anterior. O agente perde tanto o comportamento antigo quanto o limite contextual de quando ele era válido. Checks de compatibilidade de versão são particularmente letais para os sistemas baseline.
A solução proposta pelo paper é o EvoMem — um patch log append-only que é adicionado ao sistema de memória existente, sem substituí-lo. Cada mudança de ambiente vira um diff estruturado. Para reconstruir qualquer estado anterior, o agente replaya a sequência de diffs. É conceitualmente parecido com um git para o estado cognitivo do agente.
O ganho: 1,5 ponto percentual na média do EvoArena. 6,1% no GAIA. 4,8% no LoCoMo. Chain-level accuracy melhora 3,7%.
Eu gosto da arquitetura. Mas tenho um problema com o que o paper não publica: custo de latência de replay, token spend por reconstrução, comportamento quando o patch log tem milhares de versões. Um log de diffs que cresce indefinidamente eventualmente força uma etapa de compressão — que reintroduz exatamente o risco de state loss que o EvoMem se propõe a resolver. Ninguém pode ignorar esse ponto.
E 1,5 ponto em cima de 39,6% significa que falha ainda é o resultado modal, mesmo com EvoMem. A direção é certa. A solução completa ainda não existe.
O que fecha o argumento desta primeira parte é o EurekAgent. [ref: agent-environment-engineering-]
Pesquisadores de Tsinghua e Zhipu AI construíram um agente de pesquisa autônoma operando sobre quatro pilares de engenharia de ambiente. E o resultado mais limpo que eles publicam é este:
Novo estado da arte em circle packing — superando o melhor resultado anterior de IA, de 2,635986, chegando a 2,635999 — com menos de onze dólares em custo total de API.
No ResearchClawBench — 40 tarefas em 10 domínios de pesquisa — Claude Code e Codex como agentes standalone superaram todos os frameworks especializados em pesquisa, incluindo AlphaEvolve e AIDE.
A latência do kernel TriMul caiu de 2247,78 microssegundos para 2005,03 — melhora de 10,8% sobre o melhor resultado anterior de IA. O MLE-Bench subiu de 71,43% para 85,71% — ganho de 14,28 pontos percentuais. Sem fine-tuning. Sem RL. Sem training run especializado. Só fronteiras de execução mais rígidas.
Os quatro pilares que o EurekAgent operacionaliza: permissions engineering com sandboxes isolados que impedem o agente de ler seu próprio sinal de recompensa ou vazar dados de treinamento para a validação; artifact engineering com filesystem e Git-based state handoffs entre múltiplos agentes; budget engineering com hard caps de token e compute que forçam auto-regulação do escopo de exploração; e human-in-the-loop engineering com ganchos de supervisão de baixo atrito que não travam o agente.
A conclusão que o EurekAgent força é direta: o gargalo não é o modelo. É o ambiente de execução.
Isso muda o cálculo de onde você investe. Você pode gastar semanas em prompt engineering e ver retorno marginal decrescente. Ou você pode investir em sandboxing, tooling e isolamento de avaliação — e ver ganhos da ordem que o EurekAgent demonstra, sem tocar nos pesos do modelo.
Pare de otimizar prompts. Comece a endurecer fronteiras. Sandbox o runtime, isole avaliação dos artefatos do agente, e dê ao agente um filesystem Git antes de dar a ele um workflow engine.
O segundo bloco desta semana aconteceu na camada de infraestrutura — e o timing entre os três anúncios foi coordenado demais para ser coincidência.
Em três dias: Microsoft anuncia o Unified Model API no Azure, abre o pg_durable como extensão de PostgreSQL, e a Databricks lança plataforma de serving model-agnostic. Três movimentos que convergem em torno da mesma tese: gateway mais workflow primitive mais serving unificado é o stack de IA de produção que está se solidificando.
Vamos pelo Azure. [ref: azure-api-management-ships-uni]
O Unified Model API chegou a public preview no Azure API Management. A proposta: você padroniza o client em OpenAI Chat Completions format. O gateway transforma transparentemente para Anthropic Messages API, Vertex AI, Amazon Bedrock, ou Microsoft Foundry — o que você precisar no backend. Quer trocar de Claude para Gemini? Muda uma routing rule. O client não reescreve uma linha de código.
As implicações operacionais vão além do roteamento.
Governance policies — rate limits, token quotas, retry logic, o filtro llm-content-safety — aplicados uniformemente em todos os providers por uma única camada de configuração. Circuit breakers que isolam endpoints de inferência não responsivos. E o API Center MCP server chegou a general availability como endpoint de discovery unificado para a empresa — automaticamente visível para agentes conectados quando registrado.
A cobertura do content safety foi expandida: agora inspeciona argumentos de tool call MCP, texto de resposta MCP, e payloads de Agent-to-Agent. O shield-prompt attribute faz scan específico para ataques de prompt injection, com thresholds configuráveis de severidade de 0, o mais restritivo, até 7.
Mas aqui está o edge case que vai morder alguém em produção antes do fim do mês.
Em modo non-streaming, uma violação de content safety retorna um 403 limpo. Em modo streaming, a policy para de encaminhar tokens silenciosamente — sem código de erro. O client não consegue distinguir um stream truncado por violação de um completion natural sem instrumentação adicional.
Sem código de erro. Em streaming.
Você não sabe o que não recebeu. Vai precisar de instrumentação extra para detectar truncação. E a Microsoft não publicou latency percentiles, token pricing, ou throughput benchmarks para a translation layer — o que significa que você precisa basear o hop adicional por conta própria antes de ir pra produção.
Mais: o Unified Model API ainda está em public preview, então SLAs de produção não se aplicam. MCP support no APIM cobre tools, mas não resources ou prompts. O rollout é staged, com tiers v2 recebendo features primeiro. Não é o momento de assumir GA behavior.
Na mesma semana, a Microsoft abriu o pg_durable. [ref: microsofts-postgresql-extensio]
Uma extensão de PostgreSQL que move checkpointing, retry logic, e state recovery para dentro do processo do banco de dados. Sem control plane externo. Um background worker em Rust. Dois componentes: duroxide para o runtime de orquestração com replay determinístico, checkpoints, sub-orquestrações e timers; duroxide-pg para persistir instâncias, histórico e filas de trabalho em um schema dedicado dentro do Postgres.
O DSL em SQL é minimal: passos sequenciais ligados com ~>, resultados bindados a variáveis com |=>, branches paralelos mergidos com &, e df.start() que inicia uma função durável e retorna um instance ID.
Para quem já tem dados e lógica em Postgres, a proposta elimina uma lista específica de infraestrutura: tabelas de pg_cron, status columns, retry counters, polling workers, callbacks de Airflow ou Temporal. Tudo substituído por orquestração SQL-native com backup e point-in-time recovery do próprio Postgres. Disponível como pacotes Debian para PostgreSQL 17 e 18.
Os casos de uso que fazem mais sentido: pipelines de embedding vetorial, ingest com deduplicação, e aprovações human-in-the-loop que podem esperar minutos ou dias antes de avançar para o próximo passo.
Mas não é Temporal. Se seus agentes tomam decisões em Python ou Go, com lógica de aplicação arbitrária que não mapeia para passos SQL, você ainda precisa de um orchestrator dedicado. E rodar uma extensão Rust nova no tier de banco tem uma implicação operacional direta — um memory leak ou crash no background worker afeta o processo host do Postgres. Essa é uma escolha de onde você quer que o failure domain fique, não uma simplificação gratuita.
E fechando o bloco: Databricks. [ref: databricks-ai-serving-platform]
Plataforma de serving model-agnostic que unifica em uma única interface desde um classificador scikit-learn de 2 megabytes em um core de CPU até um LLM fine-tuned de 70 bilhões de parâmetros em oito GPUs.
Os números publicados: 300 mil queries por segundo no agregado da plataforma, com menos de 10 milissegundos de overhead de p99. Clientes migrando de stacks self-managed relatam redução de custo de infraestrutura de até 90%.
Runtime escolhido automaticamente: Gunicorn MLflow assíncrono para modelos clássicos, vLLM, NVIDIA Triton, ou runtime próprio do cliente para cargas GPU — tudo sob a mesma interface de serving. Todo endpoint emite telemetria para Unity Catalog via OpenTelemetry: métricas, logs, traces, e inference tables streamando cada request para Delta.
A elisão de decisão que a Databricks está vendendo é real: você não precisa mais decidir runtime, scaler, observability wiring por modelo. A plataforma infere isso do perfil do modelo e do padrão de tráfego. Deploy em um clique da etapa de treinamento para produção — com match exato de ambiente.
Com as ressalvas que o marketing não menciona: o 90% de redução de custo é específico para cenários de migração, não é steady-state. O número de 300K QPS é agregado de toda a plataforma, não capacidade de um único endpoint. Não há benchmarks independentes publicados. E cada endpoint é um deployment Kubernetes completamente isolado — o que significa cold-start e overhead de orquestração por endpoint que você precisa modelar antes de deployar dezenas de micro-classifiers ao lado de LLMs pesados.
Mas o argumento estratégico fecha. O stack está convergindo. Se você ainda tem lógica de roteamento hand-rolled entre modelos, está acumulando dívida técnica em latência e auditoria que vai aparecer na conta quando tentar escalar.
Trate o roteamento de modelos como camada de governança — não como lógica de negócio. É essa abstração que vai separar os stacks de IA de produção dos proofs of concept nos próximos dezoito meses.
Terceiro bloco. A camada mais cara, mais escassa, e mais politicamente carregada desta semana.
Compute.
Uma encomenda que, se confirmada na escala reportada, quebra um monopólio que silenciosamente controlava o teto de capacidade de inferência do mundo inteiro.
O Google reportadamente encomendou à Intel o packaging de mais de três milhões de TPUs para entrega em 2028. [ref: google-locks-in-3m-tpus-with-i]
A tecnologia é o EMIB — embedded multi-die interconnect bridge. Em vez de colocar cada die em um interposer de silício grande como o CoWoS da TSMC, o EMIB usa bridges de silício pequenas no substrato orgânico para conexões apenas entre dies adjacentes. Intel reivindica utilização de pacote próxima de 90% contra aproximadamente 60% para packaging classe interposer CoWoS.
E Bernstein estima custo de packaging EMIB em "algumas centenas de dólares por chip" contra 900 a 1000 dólares para CoWoS em um processador classe Rubin — com uma ressalva explícita inserida na própria estimativa: a vantagem é contingente em um "track record externo de produção" que ainda não existe.
Para entender por que a escala desta encomenda importa, o dado que o CEO da TSMC, C.C. Wei, deu no final de 2025: a capacidade de nó avançado da TSMC está "cerca de três vezes abaixo da demanda". NVIDIA consome aproximadamente 60% do supply global de CoWoS. Broadcom e AMD absorvem outros 26%.
Sobra aproximadamente 14% para todo mundo mais — incluindo os ASICs customizados do Google.
Então o Google não está apenas comprando capacidade de packaging. Está executando uma estratégia de dual-source: TSMC para os wafers, Intel para o assembly — e começando a qualificação com dois anos de antecedência em relação ao silício de produção. Esse é o lead time que você precisa para não ficar refém de um único ponto de falha na supply chain de aceleradores.
Mas eu não chamaria isso de vitória sem os dados que importam: yield em volume, qualificação formal do SK hynix para HBM sobre bridges EMIB — que ainda está em andamento — e clareza sobre se a Intel está fabricando os dies ou apenas fazendo o assembly. JPMorgan nota que a Intel pode estar cuidando apenas do packaging, com TSMC fabricando o silício — o que é adição de capacidade significativa, mas menos transformadora do que uma mudança completa de foundry.
Intel Foundry perdeu 10,3 bilhões de dólares em 17,8 bilhões de receita em 2025. No primeiro trimestre de 2026, clientes externos contribuíram apenas 174 milhões de dólares dos 5,4 bilhões de receita total da divisão.
Sem evidência de produção em volume. A vantagem de custo é teórica sem yield.
O takeaway para arquitetos: packaging avançado é agora o fator limitante em supply de aceleradores — não o silício. Qualificar um segundo fornecedor de packaging leva no mínimo dois anos. Se você precisa de capacidade de inferência customizada em 2027, esse processo precisava ter começado antes do fim deste trimestre.
Agora um dado de latência que muda o cálculo para cargas de inferência interativa.
D-Matrix entrou em produção completa com o Corsair — acelerador de inferência baseado em SRAM on-chip — com backing da M12, o braço de venture da Microsoft. [ref: microsoft-backed-d-matrix-chip]
Benchmarks independentes da Gimlet Labs: em um modelo draft especulativo de 1,6 bilhão de parâmetros para um target de 120 bilhões de parâmetros GPT-OSS, o tempo de resposta end-to-end caiu de 24 segundos para menos de 2 segundos quando o Corsair foi pareado com uma GPU Blackwell.
Doze vezes de melhora sobre o baseline GPU-only.
E a razão é estrutural, não um quirk de benchmark. Cada card Corsair tem 2 gigabytes de SRAM on-chip com 150 terabytes por segundo de memory bandwidth — aproximadamente vinte vezes o bandwidth de uma GPU high-end. Speculative decoding é memory-bandwidth-bound. O Corsair alimenta o modelo draft rápido o suficiente para manter a GPU principal saturada o tempo todo.
O teto de capacidade é real e não deve ser ignorado. Um servidor consegue rodar um Llama 3.1 de 8 bilhões de parâmetros quantizado. Modelos de raciocínio grandes não cabem em um design baseado em SRAM. A D-Matrix está endereçando isso com o Pavehawk, chip de próxima geração com DRAM 3D-stacked para expandir capacidade além dos 128 gigabytes de SRAM por servidor do sistema atual.
Até lá, o Corsair é um inference sidecar, não um replacement. Bernstein's Stacy Rasgon confirma clientes reais deployando Corsair "em conjunto com Nvidia" — não no lugar de.
O card custa dezenas de milhares de dólares. D-Matrix vale aproximadamente 2 bilhões de dólares após levantar cerca de 500 milhões, com entregas previstas para hiperscalers, neoclouds e frontier labs em junho de 2026 — 90% baseados nos Estados Unidos.
Para arquitetos: o use case primário são workloads de voz, chatbots, e ferramentas de agentic coding onde latência é crítica e o draft model cabe no SRAM. Não substitua a GPU fleet. Adicione Corsair como camada de latência para os workloads onde a diferença entre 2 e 24 segundos muda fundamentalmente a experiência do usuário.
E agora o reality check que fecha este bloco de compute — e que a indústria precisa ouvir sem o filtro do entusiasmo de startup.
Um rack padrão de 32 GPUs. Aproximadamente 40 kilowatts de consumo. Em órbita. Para dissipar esse calor no vácuo: 80 metros quadrados de radiador por rack. [ref: why-orbital-data-centers-will-]
Esse não é um número teórico. É a física do Stefan-Boltzmann aplicada ao TDP do H100.
Um único H100 a 700 watts TDP, mantido a 60 graus Celsius, exige 1,4 metro quadrado de radiador. A 85 graus, cai para cerca de 1 metro quadrado. A 20 graus, sobe para quase 3 metros quadrados por chip.
Um rack de 32 GPUs: 80 metros quadrados de radiador.
E esse é só o dia zero.
Após cinco anos em órbita, degradação de emissividade por radiação ionizante aumenta a área necessária em aproximadamente 40% para manter a mesma capacidade de resfriamento. Um megawatt de carga térmica a 20 graus demanda aproximadamente 1.200 metros quadrados de radiador — equivalente a quatro quadras de tênis.
A ABI Research modelou o TCO de um H100 em órbita por um ano contra um rack terrestre a 0,20 dólar por kilowatt-hora, assumindo custo de lançamento otimista de 44 dólares por quilograma via Starship: custo orbital pelo menos uma ordem de magnitude acima da operação terrestre.
Há apostas reais na mesa. O Starcloud lançou um H100 em novembro de 2025, resfriado por radiação passiva. O Google tem o Project Suncatcher, com dois satélites carregando TPUs previstos para início de 2027. O Starcloud tem um filing na FCC para uma constelação de 88 mil satélites.
E aqui está o problema que não tem solução de hardware limpa.
Chips radiation-hardened têm 30 a 50% de custo adicional e sacrificam 20 a 30% de performance comparado ao silício terrestre. Eles não têm densidade de compute para rodar LLMs modernos. Então você voa H100s e TPUs "soft" — aceitando cosmic-ray bit-flips e latch-ups como ruído ambiente operacional.
Painéis solares precisam apontar para o sol. Radiadores precisam apontar para longe. Isso é um conflito de pointing que scheduling de software não resolve. E os links ópticos de multi-terabit que o Google precisa para o Suncatcher precisam manter alinhamento entre satélites em movimento com drift orbital — adicionando latência e risco de pacote antes de um único token chegar à Terra.
O break-even econômico, segundo a análise da IEEE Spectrum e confirmado pela própria equipe do Google, exige custo de lançamento abaixo de 200 dólares por quilograma até 2035.
Para missões de nicho — pré-processamento de dados de observação terrestre, rastreamento hipersônico em tempo real, collision avoidance ativo em LEO — a física faz sentido. O compute está co-localizado com o sensor. A latência de downlink deixa de existir.
Para inferência de uso geral: não faz.
Até que o custo de lançamento caia abaixo de 200 dólares por quilograma, e um rack de 40 kilowatts sobreviva a um ciclo de cinco anos de degradação de radiador sem virar uma âncora térmica, data centers orbitais são uma demonstração de física — não um stack de produção.
Esta semana, o modelo parou de ser a variável que você controla. O ambiente de execução, o gateway de roteamento e o silício de packaging viraram o locus de vantagem competitiva — e todos os três têm gargalos físicos ou operacionais que nenhum anúncio apaga. Wire na segunda: o que de fato foi pra produção no meio de todos esses anúncios — e quem está pagando a conta da capacidade de inferência. Boa semana.