Da linha de comando à era agêntica: o que aprendi no Google Cloud AI Builders 2026

Estimated reading time: 10 minutos

A inteligência artificial está cada vez mais inserida no desenvolvimento e arquitetura de software, e já passamos da fase dos simples chatbots de apoio para codificação faz tempo.

2024 e 2025 consolidaram o uso de modelos de linguagem como copilotos no editor. Agora em 2026, estamos vendo uma transição definitiva para a Engenharia Agêntica (AI Agents) — onde agentes autônomos planejam, executam, monitoram e corrigem sistemas ponta a ponta.

Ontem, 26.08.26, aconteceu o Google Cloud AI Builders 2026 no escritório do Google aqui em São Paulo com o objetivo de reunir profissionais para discutirmos como a automação de qualidade e inteligente está redefinindo o ciclo de vida dos softwares, operações de infraestrutura e o papel dos times técnicos.

Infelizmente não consegui ficar em todo o evento, mas trago aqui alguns insights dos conteúdos que eu estive presente.

O dev como orquestrador de contexto

Um dos pontos que mais me chamaram a atenção foi o fortalecimento da mudança de postura necessária para quem constrói software nessa era de agentes autônomos.

Está cada vez mais rápido e acessível a construção de código, no entanto, a qualidade da entrega depende diretamente da clareza do contexto e dos limites (guardrails) fornecidos para a IA. O desenvolvedor deixa de ser apenas um “executor” de linhas de comando e se torna o orquestrador, curador e auditor do ecossistema agêntico, podendo assim, não só se preocupar com como entregar a solução mas fazendo parte também da tomada de decisão e regras de negócio para uma melhor entrega.

O contexto como produto (`gemini.md`)

Assim como são documentados os contratos de API e diagramas de arquitetura, a definição de contexto dos agentes precisa ser tratada como um artefato vivo no repositório:

Padronização de contexto: arquivos de especificação centralizados (como arquivos .md de contexto estruturado) definem stack, restrições e regras de negócio.
Restrições imperativas e negativas: instruções claras sobre o que o agente nunca deve fazer (por exemplo: nunca expor chaves de API, nunca alterar versões de produção sem intervenção humana).
- O uso do “nunca” será melhor que o uso do “não” nas definições do que o agente não deve supor ou executar.
Isolamento de tarefas: dividir grandes iniciativas entre sub-agentes especialistas (frontend, backend, SRE/banco) reduz o consumo desnecessário de tokens e assim, impede que o histórico de conversas polua o raciocínio do modelo.

Com essas definições bem claras, a execução do agente fica mais precisa e com menos ou quase nada de alucinações.

Operações de infraestrutura inteligente – Kube-Agents

Esse aqui é um assunto totalmente novo pra mim porque não sou muito da área de DevOps, mas achei bem interessante e vale o subtópico (mesmo porque eu gravei o audio e o Gemini fez o TLDR para mim).

Na apresentação do Gary Singh (Product Manager do Google Kubernetes Engine), foi falado de como o paradigma do ChatOps tradicional está evoluindo para agentes proativos de plataforma com o projeto open-source Kube-Agents.

+-------------------------------------------------------------------+
|                        GKE Control Plane                          |
+-------------------------------------------------------------------+
                                  │ (Cluster Events / Logs)
                                  ▼
+───────────────────────────────────────────────────────────────────+
|                  Proactive Event Listeners & MCP                  |
|          (Detecta: CrashLoopBackOff, OOMKilled, Quotas)           |
+───────────────────────────────────────────────────────────────────+
                                  │
                                  ▼
+───────────────────────────────────────────────────────────────────+
|                     Kube-Agents Controller                        |
|       (Triagem com Modelos Leves + Raciocínio Gemini)             |
+───────────────────────────────────────────────────────────────────+
                                  │
                                  ▼
+───────────────────────────────────────────────────────────────────+
|                        GitOps Remediation                         |
|        (Pull Request com proposta de correção + Auditoria)        |
+───────────────────────────────────────────────────────────────────+

E como eu disse, isso é totalmente novo pra mim, mas o Gemini pontuou os diferenciais do Google Kubernetes Engine (GKE) mostrados por ele:

Detecção proativa de falhas: em vez de esperar uma consulta manual as anomalias são capturadas de forma natural e automática.
Integração padronizada via MCP: utilização do Model Context Protocol (MCP) para consultar métricas, inspecionar manifestos e auditar o estado do cluster de forma estruturada.
Segurança por padrão (read-only + GitOps): os agentes operam em modo de leitura e sugerem correções criando pull requests ou relatórios detalhados, mantendo a aprovação final e a governança nas mãos dos engenheiros.

E em que que isso me ajudou? Em nada…. mas achei interessante (rss).

Isolamento e execução segura de código

Ainda falando do GKE, outro tema que me chamou a atenção foi a segurança oferecida na solução para execução de scripts e ferramentas geradas dinamicamente por agentes ou usuários externos. A ideia principal foi mostrar como rodar um código não confiável sem comprometer o resto do sistema?

Inclusive, fomos provocados com essa pergunta: vocês confiam no código gerado pela IA? Ninguém levantou a mão, daí o Fabrício Veronez, o palestrante, nos mostrou como podemos reveter esse cenário com uma combinação do GKE Autopilot e gVisor que é uma sandbox:

gVisor (sandbox isolation): cria uma camada virtual segura que intercepta chamadas no nível do sistema operacional, blindando o kernel do host contra vazamento de dados ou ataques. Ele comentou também que no iOS isso é feito com o sandbox do próprio sistema.
Orquestração assíncrona: o fluxo utiliza o Cloud Pub/Sub para o controle das filas de execução, controladores de sandbox para instanciar os Pods isolados e o BigQuery para compilar métricas de execução e critérios de avaliação.
Governança no Gemini Enterprise: centralização de cotas, gestão de pipelines e integração transparente com modelos de código aberto via Model Garden (Gemma, Llama ou DeepSeek). Um adendo aqui, o Gemini Enterprise é o antigo Google Vertex.

O que eu peguei de aprendizado aqui foi justamente essa questão de isolar a validação do código em outro ambiente. O Fabrício trouxe até o exemplo de validação de códigos feitos em hackathons e como esses agentes facilitam esse processo de forma segura.

Otimização de custos e estratégias de harness

Essa foi uma das minhas palestras preferidas, já que eu estou estudando bastante sobre harness engineering. Eu fiz até um post sobre o tema. Leia aqui: Spec-Driven Development e Harness Engineering: o início da MINHA saga

Criar agentes que funcionem bem não deixou de ser um desafio de prompts e se tornou de viabilidade econômica e retorno sobre investimento (ROI). Se você não sabe mensurar o retorno, você só está fazendo um experimento.

Isso se resume a um ponto central: o que é “caro” ou “barato” em IA é relativo e depende diretamente do valor entregue, da confiabilidade da solução e da arquitetura de custos adotada.

Algumas das práticas de engenharia de harness recomendadas para alguns desafios foram:

O desafio	A solução arquitetural
Custo de inferência	Arquitetura híbrida: triagem inicial com modelos rápidos/locais (Gemma via ADK) e escalonamento para modelos maiores (Gemini) apenas em problemas de alta complexidade.
Janela de contexto inflada	Extração de metadados antes de injetar logs no LLM; uso de ferramentas especializadas em vez de despejar arquivos brutos de configuração.
Alucinações em pipelines	Implementação de comitês avaliadores (juízes) determinísticos que validam conformidade e segurança antes da geração do código final.

A IA só traz ROI positivo quando deixa de ser tratada como um assistente solto (“o modo amém”) e passa a ser integrada a uma arquitetura com harness, limites de custo e governança clara. A velocidade na entrega só gera valor real se vier acompanhada de estabilidade e previsibilidade de custos.

Inghts finais

Gerar código ficou barato; o novo gargalo é a infraestrutura e governança. – Criar código ou scripts com IA tornou-se rápido e acessível a qualquer pessoa (inclusive não técnicas).

No entanto, se esse código gerar incidentes em produção, falhas de segurança, bloqueios na esteira de deploy ou consumo descontrolado de nuvem e tokens, o “ganho de velocidade” vira prejuízo financeiro e operacional.

Outro ponto foi é que de fato o profissional deve sair do “só vou executar e entregar a solução” e ir para “vou planejar, definir bem as regras e orientar a IA para fazer isso”. Vejo que muitos profissionais ainda estão resistentes a essa mudança, e está cada vez mais claro que esses ficarão pra trás.

O que você está fazendo para acompanhar isso? Eu sei que eu estou aplicando e estudando bastante (e tratando a IA como a minha melhor amiga para quando ela dominar tudo eu não ser escravizada rss).