Notas do Cloud Next 2026: Desenvolvimento Orientado por Spec, Visto da Sala

Esta é a segunda de cinco notas de campo do Google Cloud Next 2026. Fui presencialmente. Fui humilde. As palestras desta conferência nunca seriam revelações — e a maior parte do valor de estar na sala é exatamente esse: confirmar o que já não é mais controverso.

A sessão que mais se alinhou com a forma como estamos trabalhando na Victorino foi a sobre desenvolvimento orientado por spec. Dois engenheiros do Google levaram a sala por dentro de como times internos estão usando especificações escritas como o contrato entre humanos e agentes de IA que escrevem código. Nada na metodologia era novo. O útil foi ver o Google se comprometer publicamente com uma prática que estamos construindo silenciosamente no trabalho com clientes há meses.

Quero registrar o que foi dito, o que me pareceu honesto, e uma conexão com a nossa prática que ainda não vi feita em lugar nenhum.

Os Dois Extremos Que Eles Enquadraram

A abertura da palestra desenhou os dois extremos de um espectro.

De um lado, assisted coding. Humano no comando. A IA completa o próximo token, a próxima função, o próximo esqueleto de teste. Previsível. Lento. Pouca alavancagem, porque o humano contínua sendo o gargalo de cada decisão arquitetural.

Do outro lado, vibe coding. Prompts em linguagem natural produzem sistemas. Rápido. Frequentemente impressionante em demo. Quase sempre ininteligível em produção, com brechas de segurança e raramente alinhado às restrições reais do time. Os sistemas funcionam até encontrarem a segunda pessoa que precisa lê-los.

Desenvolvimento orientado por spec fica no meio. O argumento foi que nenhum dos extremos sobrevive ao contato com uma organização real de engenharia. Assisted coding não entrega a alavancagem que a liderança está pedindo. Vibe coding produz artefatos que nenhuma revisão de governança aprova. O caminho do meio é aquele em que o humano escreve a especificação, a IA implementa contra ela, e o spec é o artefato que os dois lados tratam como fonte da verdade.

Vou ser honesto: já ouvi esse enquadramento antes. Quem leu um design document, também. O útil foi ouvir isso dito pelo Google, no palco do Cloud Next, como prática interna deles.

A Citação Que Ancorou a Palestra

O slide que me marcou foi uma frase de Leslie Lamport: “Para pensar, temos que escrever. Se você está pensando sem escrever, você só acha que está pensando.”

Lamport vem fazendo esse argumento há quarenta anos. O trabalho com TLA+, os textos sobre especificar antes de implementar, a insistência longa de que a resistência dos engenheiros a escrever as coisas não é pragmatismo, é fuga. Nada disso é novo. O que era novo era ver a frase citada como âncora filosófica de uma prática de engenharia com IA — e ver a sala concordando.

Especificação não é melhoria de fluxo. É o ato de forçar o pensamento. A IA não é o motivo para começar a escrever specs. É o motivo de o custo de não escrever ter acabado de subir.

O Que Eles Disseram Que Vai num Spec

Os apresentadores propuseram cinco seções. Estou anotando porque a estrutura é útil, não porque seja canônica:

Princípios do produto ou do projeto. As restrições que não mudam — postura de segurança, compromissos arquiteturais, o que é inegociável.
Especificação do produto. O que o sistema faz. O “o quê”.
Arquitetura de software. Como o sistema é construído. O “como”.
Critérios de aceitação e testes. O que significa “pronto” e como é verificado.
Lista de tarefas. A decomposição que o agente vai percorrer.

Quem escreveu um design document na última década não vai achar nada disso estranho. O que muda quando o agente de IA é o implementador é que cada seção passa a sustentar peso de uma forma nova. A seção 1 vira a fronteira de política do agente. A seção 4 vira a condição de saída do agente. A seção 5 vira a fila de trabalho do agente. O documento deixa de ser registro de intenção e passa a ser contrato executável.

O Exemplo do Time do Canvas

A parte mais concreta da palestra foi um caso de produção do time Canvas do Google — o time que constrói extensões para o Gemini CLI. O apresentador, Yanzhi, descreveu o fluxo. O time usa cerca de cinquenta sub-agentes, cada um com escopo restrito a uma responsabilidade. Requisitos de produto e engenharia ficam em markdown, versionados junto com o código. O spec não é uma página de wiki. É um arquivo no repositório, revisado em pull request como qualquer outro artefato.

Os ganhos relatados foram específicos. Verificação de demos de ponta a ponta — o agente roda a demo, confere as saídas, registra o que falhou. Correções de acessibilidade — o spec descreve o compromisso de acessibilidade, o agente identifica violações e propõe patches. Fluxo de controle de versão — branches, commits, descrições de PR, o trabalho repetitivo de manter o repositório legível.

Eles quantificaram a economia em dezenas de horas por semana, por pessoa. Não tenho como verificar o número de dentro da plateia. O que posso dizer é que o fluxo descrito bate com o que vemos na Victorino quando um time cliente acerta a disciplina de spec: o agente absorve o trabalho que nenhum humano queria fazer mesmo, e o humano sobe para escrever o spec.

A Citação Que Não Estava Nos Slides

De passagem, o apresentador citou Dave Anderson, distinguished engineer do Google, sobre qual é o artefato mais valioso num fluxo orientado por spec. A resposta dele foi: o próprio design document.

Não o código. Não os testes. Não o deploy. O design document.

Essa é a parte do argumento que encontra resistência em toda organização de engenharia em que já trabalhei. Engenheiros — eu inclusive, durante a maior parte da carreira — tratam o design document como imposto. Escrever uma vez, perder no wiki, nunca consultar de novo. O que o desenvolvimento orientado por spec diz é que o documento é a coisa durável. O código é regenerado. Os testes são regenerados. Os agentes são rotacionados. O documento sobrevive, e é o único artefato que se acumula entre iterações.

Se isso é verdade, a implicação é desconfortável: o output sênior de engenharia da próxima década é escrita, não código.

As Sete Lições

A palestra fechou com sete lições do uso interno no Google. Vou listar achatado porque o valor está no inventário:

Aceite a mudança de mentalidade. Pare de tratar o spec como documentação. Trate como entregável.
Estruture o repositório para legibilidade da IA. Nomes, layout, modularidade — o que é bom para humanos é bom para agentes, só que mais.
Escreva specs de forma colaborativa. O spec não é redigido isoladamente por um arquiteto; é co-construído pelo time que vai operar o resultado.
Versione o spec. PRs contra o spec, não só contra o código.
Use o modelo mais profundo no design e modelos mais leves para gerar código. O pensamento caro acontece a montante do trabalho.
Gerencie habilidades de forma modular. Sub-agentes com escopo estreito, não um agente onisciente.
Volte a documentar ao concluir. Quando o trabalho termina, o spec é atualizado para refletir o que foi de fato construído, não o que foi originalmente proposto.

Estou lendo essas lições e pensando que qualquer organização de engenharia com uma cultura de design dos anos 2010 já faz cinco das sete. A lista não é uma revelação. É uma autorização.

Minha Adição: O Prompt de Negócio É o Spec

Aqui está a conexão que ainda não vi feita em lugar nenhum, e o motivo de eu estar registrando isso para o nosso time e para os clientes.

No trabalho que a Victorino faz, o spec nem sempre é um design document. Para uma fatia significativa do trabalho conduzido por agentes — aquele em que um usuário de negócio compõe tarefas para o agente sem uma camada de engenharia no meio — o spec é o prompt de negócio. Os poucos parágrafos que o usuário escreve para definir o que o agente deve fazer. As restrições. Os critérios de sucesso. As fronteiras.

Esse prompt está cumprindo as cinco funções do spec descritas pelos engenheiros do Google. Princípios. Especificação. Arquitetura (implícita, herdada das ferramentas do agente). Critérios de aceitação. Decomposição de tarefas. O prompt está fazendo o trabalho que o design document fez no caso de engenharia.

O que significa que a disciplina transfere direto. Trave o prompt antes de travar os MCPs. Trate o prompt como o artefato que se acumula. Versione. Revise. Volte a documentar quando ele mudar. Os MCPs podem ser trocados. O modelo pode ser atualizado. O prompt — a articulação do que o trabalho é — é a coisa que precisa sobreviver.

Já escrevemos em outros textos sobre specs de agentes como artefatos de governança, sobre specs para agentes de IA, sobre a camada de especificação na governança de agentes e sobre o symphony como camada de controle. A palestra do Cloud Next não reformulou nada disso. O que ela fez foi confirmar que a mesma ideia agora aparece dentro dos times de produção do próprio Google, com o mesmo nome. A metodologia não é nova. O compromisso público é.

Para a segunda-feira de volta com os clientes, isso já é o suficiente.

Fontes

Google Cloud. “Google Cloud Next 2026.” Abril de 2026.
Wikipedia. “Leslie Lamport.” Abril de 2026.
Notas pessoais do autor, presencial em Las Vegas.

A Victorino ajuda times a adotar a disciplina de spec-driven como contrato de governança entre intenção de negócio e execução de IA: contato@victorino.com.br | www.victorino.com.br