A a16z Nomeou a Virada; Linear e Google Entregaram na Mesma Semana

Na segunda semana de maio de 2026, a a16z publicou um ensaio defendendo que a próxima franquia durável de software fica uma camada acima do banco de dados, não dentro dele. Eles chamaram essa camada de “Sistema de Inteligência” e a posicionaram como o nível de orquestração que consome registros, raciocina sobre eles e dispara trabalho. Dois dias depois, a Linear lançou o Code Intelligence e colocou raciocínio sobre repositório nas mãos de gerentes de produto, agentes de suporte e executivos de conta. No dia seguinte, o Google Cloud lançou a Gemini CLI DevOps Extension, um agente que provisiona pipelines de CI/CD na GCP a partir de um prompt em chat, mantendo-se dentro das permissões IAM do operador.

Três lançamentos. Uma tese. A camada de orquestração está se tornando ao mesmo tempo o novo fosso competitivo e a nova superfície de governança, e a trilha de auditoria que você ainda anexa ao banco está, agora, anexada ao andar errado.

O Recorte da a16z, em Versão Compacta

Gio Ahern, Steph Zhang e Alex Immerman publicaram From System of Record to System of Intelligence no a16z.news. O argumento cabe na memória.

A Salesforce vale cerca de US$ 140 bilhões. A HubSpot vale cerca de US$ 9 bilhões. São os Sistemas de Registro canônicos para trabalho de go-to-market e não serão deslocados por mais um banco de dados com schema mais elegante. Serão reenquadrados como substrato. A ação sobe um andar.

A conta que os autores entregam é a parte para levar a sério. Software de GTM é de 5 a 10 por cento do gasto total em GTM. Os outros 90 a 95 por cento são trabalho humano: SDRs, AEs, analistas de RevOps, engenheiros de suporte, marketing operando campanhas. Um Sistema de Inteligência captura valor não por substituir o CRM, mas por comprimir o trabalho que se acumula sobre ele. O CRM permanece. O uso do CRM, na verdade, subiu com a adoção de IA, não caiu, porque o orquestrador precisa de mais registros, mais limpos e melhor tagueados para raciocinar sobre eles. O substrato fica mais valioso. A franquia se desloca.

Esse é o recorte estratégico. Os dois lançamentos da mesma semana são a instanciação.

Linear Code Intelligence: O PM Raciocina Sobre o Repositório

O changelog de 14 de maio da Linear lançou o Code Intelligence em beta público para os planos Business e Enterprise. O produto faz o que o nome diz. Conecta a Linear à base de código e permite que um não-engenheiro faça perguntas ancoradas em código: quais PRs tocaram esta feature, quais arquivos implementam este fluxo, qual é o raio de impacto se mudarmos este contrato.

O público é a parte que merece atenção. Não é uma ferramenta para engenheiros. Engenheiros já têm code intelligence integrada à IDE. A Linear mirou em gerentes de produto, agentes de suporte ao cliente e representantes de vendas. A promessa é que um CSM diagnosticando um problema de cliente possa perguntar “qual deploy quebrou isso” e receber uma resposta ancorada em código sem acionar um engenheiro. O PM escopando uma feature pode perguntar “o que a implementação atual de fato faz” sem agendar uma reunião de 30 minutos.

A Linear fez o trabalho de governança. Controles de admin definem quais repositórios entram no escopo e qual escopo de permissão se aplica. Código não é exfiltrado para um vetor genérico. O raciocínio acontece dentro do mesmo workspace que já governa o acesso ao projeto. A orquestração é por workspace, por role, por repositório.

Repare no que isso faz com o organograma. O CRM, o rastreador de issues e a base de código viviam em três mundos operacionais distintos. A camada de orquestração colapsa essa separação. O PM, o CSM e o AE passam a raciocinar sobre os três pela mesma superfície. O “sistema de registro” que cada função possuía virou input de um “sistema de inteligência” compartilhado.

Gemini CLI DevOps Extension: O Operador Continua Editor-Chefe

O post de Karl Weinmeister em cloud.google.com lançou a Gemini CLI DevOps Extension na mesma semana. A arquitetura merece ser desmontada, porque é a tese da orquestração construída em código.

Três camadas se empilham. Um conjunto de Skills define o que o agente pode fazer (provisionar um trigger no Cloud Build, configurar um Artifact Registry, configurar um deploy no Cloud Run). Um servidor MCP em Go embrulha as APIs subjacentes da GCP. Uma base de conhecimento RAG local ensina ao agente o ambiente do operador, suas convenções e decisões anteriores, de modo que o mesmo prompt produza a resposta certa para aquele time, e não uma resposta genérica de GCP.

As escolhas de governança são a parte que pede grifo.

Varredura de segredos antes do deploy roda antes de qualquer apply. O agente opera dentro das Application Default Credentials existentes do operador, ou seja, não pode fazer nada que o operador também não possa. O operador aprova cada mudança antes da execução. O enquadramento do Google é explícito: o humano permanece “Editor-Chefe”. O agente esboça; o operador comita.

Esse é o padrão Sistema de Inteligência vestido de DevOps. O substrato é a própria GCP, o Sistema de Registro da configuração de nuvem. O orquestrador não substitui o modelo de IAM, o log de auditoria ou o pipeline de deploy. Ele se posiciona uma camada acima e transforma “quero um pipeline de CI/CD para este serviço” em um conjunto de mudanças em rascunho que o operador lê, edita e aprova.

Por Que Isso é o Novo Fosso

Um Sistema de Registro vence por gravidade de dados e custo de troca. Você não tira dez anos de oportunidades, contatos e pipeline da Salesforce porque o custo de migração engole qualquer diferencial de feature que um concorrente possa oferecer. O fosso são os dados e as integrações que entram neles.

Um Sistema de Inteligência vence por uma física diferente. O fosso é qualidade do raciocínio, acesso governado ao substrato e o loop que melhora ambos enquanto roda. O orquestrador que ganha melhores políticas, melhor tool-calling, melhor grounding, melhores trilhas de auditoria e mais confiança do operador vence, mesmo que os registros subjacentes sejam de outro fornecedor.

É por isso que o recorte da a16z importa agora e não em 2024. Há dois anos, a camada de orquestração era um chatbot parafusado em cima do CRM. Os fornecedores do substrato podiam absorvê-la. Hoje, a camada de orquestração é um workspace que governa identidade, escopo e política em vários substratos ao mesmo tempo. O Code Intelligence da Linear raciocina sobre registros da Linear e a base de código. A Gemini CLI raciocina sobre serviços da GCP. O orquestrador é o novo perímetro, e os fornecedores de substrato ficam a jusante dele.

A franquia se move para quem detém a superfície de orquestração de um determinado operador. A franquia não vai ser uma única empresa. Vai ser uma empresa por contexto operacional: uma para engenharia, uma para go-to-market, uma para finanças, uma para jurídico, possivelmente uma por função nas grandes empresas. A corrida é para ser o orquestrador de confiança de uma função definida antes que os fornecedores de substrato lancem o deles.

Por Que Isso é a Nova Superfície de Governança

Toda trilha de auditoria que você tem hoje provavelmente está anexada ao substrato. Você loga escritas no banco. Loga chamadas de API no provedor de nuvem. Loga mudanças no rastreador de issues. A postura de compliance que você consegue defender diante de um auditor está construída sobre logging no nível do substrato.

A camada de orquestração quebra essa postura em três frentes.

Primeiro, o orquestrador decide quais chamadas fazer ao substrato. O substrato registra a chamada com fidelidade, mas o raciocínio que a produziu vive no orquestrador. Se você não consegue provar por que um agente disparou uma consulta SQL, você não defende a consulta, mesmo que ela esteja logada.

Segundo, o orquestrador atravessa substratos. Uma única ação orquestrada pode tocar o CRM, a base de código, o provedor de nuvem e o rastreador de issues. Os logs de auditoria do substrato não conseguem reconstruir a ação. Só o orquestrador consegue.

Terceiro, o orquestrador é onde as decisões de acesso de fato acontecem. O Code Intelligence da Linear aplica escopo de repositório por workspace, não por consulta ao banco. A Gemini CLI aplica o que o agente pode fazer pelas ADC do operador, não pelo log de auditoria da GCP. A superfície de controle de acesso agora é o motor de política do orquestrador.

A implicação é inescapável. Trilhas de auditoria e controle de acesso precisam acompanhar o orquestrador. Se o seu programa de governança assume que o banco de dados é a fonte da verdade para “quem fez o quê”, o seu programa de governança está um andar abaixo do necessário.

Faça Isso Agora

Se você lidera um time de plataforma, três ações merecem entrar na agenda desta semana.

Escolha um substrato em que um orquestrador já opera contra os seus dados. O CRM com um assistente de IA. O provedor de nuvem com uma extensão de agente. O rastreador de issues com code intelligence. Mapeie o que o orquestrador pode fazer e sob qual identidade ele atua. Se a resposta for “a identidade do usuário, com as permissões completas do usuário, e confiamos no log de auditoria do fornecedor”, anote isso como sua postura atual. Provavelmente não é a postura que você quer em produção.

Puxe o log de auditoria que o orquestrador emite, separado do log do substrato. Compare-os. O log do substrato vai mostrar as chamadas. O log do orquestrador vai mostrar o raciocínio. Se o orquestrador não emite um log de raciocínio que você possa exportar, redigir e reter nos seus termos, você tem uma dependência de auditoria do fornecedor que vai virar dependência de compliance na primeira vez que um regulador perguntar.

Escreva uma política de uma página que defina quais substratos cada orquestrador pode tocar, quais identidades ele pode assumir e quais ações exigem aprovação humana antes da execução. A Gemini CLI DevOps Extension exige aprovação do operador para cada mudança como padrão. Trate isso como o piso, não o teto. O orquestrador que roda sem supervisão é o orquestrador que produz o incidente que os logs do substrato não conseguem explicar.

Na mesma semana em que a a16z nomeou a virada, dois fornecedores entregaram produtos que provam que a virada já está em produção. Os fornecedores de substrato não vão sumir. A franquia está se mudando para o andar de cima. Sua governança precisa se mudar junto.

Já escrevemos antes sobre como isso se desenrola em superfícies adjacentes. Três preços, um agente cobriu a pergunta de preço sobre quem paga pela orquestração. O imposto de integração de agentes cobriu o padrão de registro que mantém sistemas multi-agente coerentes. Infraestrutura governada de agentes em escala cobriu o substrato que torna qualquer disso seguro de operar. Este texto é o recorte estratégico. A camada de orquestração é o fosso e a superfície de governança, e a semana de 11 de maio é o momento em que ambos se tornaram impossíveis de discutir.

Fontes

a16z. “From System of Record to System of Intelligence.” Maio de 2026.
Linear. “Linear Code Intelligence.” Maio de 2026.
Google Cloud. “Ship Code Within Minutes with the Gemini CLI DevOps Extension.” Maio de 2026.

A Victorino ajuda lideranças de plataforma e produto a desenhar auditoria e controle de acesso para a camada de orquestração que os fornecedores estão agora construindo: contato@victorino.com.br | www.victorino.com.br