Vibe coding vs. agentic engineering: o novo SDLC segundo o Google

Caiu na minha mão uma masterclass do Google em PDF — 51 páginas, assinada por Addy Osmani, Shubham Saboo e Sokratis Kartakis, chamada “The New SDLC With Vibe Coding”. Li inteira e vou ser honesto: é o melhor mapa que vi até agora de como o ciclo de desenvolvimento de software está sendo remontado pela IA. Não é hype de “a IA vai te substituir” — é um framework técnico de como sair do vibe coding de fim de semana pra agentic engineering de produção. Vou destrinchar todo o conteúdo aqui, ponto por ponto, com a minha leitura no meio.

Da sintaxe à intenção: o que realmente mudou

A tese de abertura é forte: a maior mudança da engenharia de software não é uma linguagem ou framework novo — é a transição de escrever código para expressar intenção e confiar que sistemas inteligentes traduzem isso em software funcionando. Por décadas, a interface do dev com a máquina foi a sintaxe: chaves, ponto e vírgula, anotações de tipo. Essa era está acabando.

Os números que o paper joga pra sustentar isso são pesados: no começo de 2026, 85% dos devs profissionais já usam agentes de IA pra codar, 51% usam todo dia, e cerca de 41% de todo código novo é gerado por IA. A evolução foi em escada: autocomplete → sugestões inline de funções inteiras → chat em linguagem natural → agentes autônomos que clonam repositório, planejam mudanças multi-arquivo, executam em sandbox, rodam testes e abrem pull request — sem ninguém digitar uma linha.

O espectro: do vibe coding ao agentic engineering

O termo vibe coding nasceu de um post do Andrej Karpathy em fevereiro de 2025: “entregue-se às vibes, esqueça que o código existe”. Você descreve em linguagem natural, aceita o que vem, e quando quebra, cola o erro de volta e pede pra IA consertar. Virou viral porque deu nome a algo que muita gente já fazia — mas aí passou a significar qualquer coisa e perdeu o sentido. No começo de 2026 o próprio Karpathy admitiu que o enquadramento era estreito demais e cunhou agentic engineering pra ponta disciplinada do espectro.

E o paper trata os dois como extremos de um espectro, não um binário. O que diferencia não é se você usa IA, mas quanta estrutura, verificação e julgamento humano cercam a saída dela. A tabela deles cruza seis dimensões — especificação de intenção, verificação, entendimento do código, tratamento de erro, escopo apropriado e perfil de risco — saindo de “prompts casuais / parece que funciona / código descartável” até “specs formais / suítes de teste e LM judges / sistemas de produção”.

O divisor de águas, e isso me marcou, é como a saída é verificada. No agentic engineering dois mecanismos andam juntos: testes verificam a parte determinística (esse input gera esse output) e evals (avaliações) verificam o que não é determinístico — o agente seguiu a trajetória certa, escolheu as ferramentas certas, entregou no padrão de qualidade. Testes são checados por código; evals por datasets rotulados, rubricas e LM judges. Sem os dois, é vibe coding — não importa quão sofisticado seja o prompt.

Context engineering: a habilidade que virou o jogo

Aqui está, pra mim, o capítulo mais importante. A qualidade do código gerado depende menos da esperteza do prompt e mais da qualidade do contexto. Isso virou disciplina própria — context engineering. O paper lista seis tipos de contexto que todo agente precisa: instruções (papel, metas e limites do agente), conhecimento (docs, diagramas, dados de domínio), memória (logs de sessão e estado persistente), exemplos (few-shot e padrões do código), ferramentas (as APIs e scripts que ele pode chamar) e guardrails (restrições rígidas e validações).

E a decisão de arquitetura que separa os bons sistemas: contexto estático vs. dinâmico. O estático é sempre carregado — instruções de sistema, arquivos de regra como AGENTS.md, CLAUDE.md, GEMINI.md, memória global. É caro porque cada token está presente em toda interação. O dinâmico é carregado sob demanda — skills disparadas por match de tarefa, resultados de ferramentas, documentos de RAG. É eficiente porque você só paga o token quando precisa. Muito estático desperdiça tokens e dilui o sinal; pouco demais e o agente esquece regra crítica. Sobre montar bons arquivos de regra eu já tinha escrito nas 13 práticas essenciais de CLAUDE.md.

O padrão mais poderoso pra gerenciar contexto dinâmico são os Agent Skills: pacotes portáveis de conhecimento procedural que o agente só carrega quando a tarefa pede, via progressive disclosure — ele vê só um metadado leve no início, carrega as instruções completas quando bate a tarefa, e puxa referência profunda só quando precisa. Assim um agente carrega dezenas de capacidades especializadas pagando o custo de token só da que está usando. Eles resolvem quatro dores: context rot de prompts sobrecarregados, ausência de memória procedural, overhead de arquiteturas multi-agente e portabilidade entre ferramentas.

O novo SDLC, fase por fase

A IA comprime o ciclo, mas de forma desigual: implementação que levava semanas cai pra horas, enquanto requisitos, arquitetura e verificação seguem em ritmo humano. O resultado não é um SDLC mais rápido — é um workflow diferente, com fronteiras borradas entre fases e o dev virando desenhista de sistema e árbitro de qualidade.

Fase a fase: em requisitos e planejamento, a IA gera user stories de um brief, acha edge cases que humanos perdem, produz schemas de API a partir de linguagem natural e cospe protótipos interativos em minutos. Em design e arquitetura — a fase mais teimosamente humana, porque é sobre trade-offs (consistência vs. disponibilidade, build vs. buy) — a IA brilha em implementar a decisão depois de tomada, não em tomá-la. Na implementação, os ganhos são reais (surveys falam em 25 a 39% de produtividade), mas o paper é honesto: um estudo da METR achou devs experientes levando 19% mais tempo em certas tarefas, por causa do tempo verificando e corrigindo a saída da IA. A implementação não some — ela vira revisar, guiar e verificar.

Em teste e QA, entram duas avaliações: a de saída (o código compila, os testes passam?) e a de trajetória (a sequência de chamadas e o raciocínio fizeram sentido?) — uma saída fluente que pulou os passos de verificação é mais perigosa que um erro visível. Em code review e deploy, a IA vira revisor de primeira passada (bugs, estilo, vulnerabilidades) sem substituir o humano, e os pipelines ficam “AI-aware” (rollback automático, previsão de risco). E a transformação mais subestimada é a manutenção: código “arriscado demais pra tocar” porque só o autor original entendia agora pode ser refatorado e modernizado com a IA lendo e respeitando a arquitetura existente. Dívida técnica que nunca seria paga, finalmente paga.

O modelo de fábrica e o harness

O modelo mental que costura tudo é o modelo de fábrica: o output principal do dev deixa de ser o código e passa a ser o sistema que produz código. Esse sistema tem specs e contexto, agentes que traduzem spec em implementação, testes e quality gates, feedback loops que devolvem falhas pro agente corrigir, e guardrails. Um gerente de fábrica não monta cada peça à mão — ele projeta a linha e garante o controle de qualidade. O sucesso vem de dar aos agentes critérios de sucesso, não instruções passo a passo.

E se o dev é o gerente, o modelo de IA é só o motor no chão de fábrica. Um motor sozinho não fabrica carro — precisa de correias, sensores e linha de montagem. Essa engenharia em volta é o harness: a equação que o paper crava é Agente = Modelo + Harness. O harness inclui instruções e arquivos de regra, ferramentas (e a prosa que diz quando chamá-las), sandboxes, lógica de orquestração (spawn de subagentes, roteamento de modelo), guardrails/hooks (código determinístico que roda antes de um commit, por exemplo) e observabilidade (logs, traces, custo, latência). Eu já tinha falado disso no post sobre o harness como camada entre modelos e agentes, e esse paper deu o nome técnico que faltava.

O ponto que mais vende a ideia é mensurável: no Terminal Bench 2.0, um time tirou um agente de fora do Top 30 pro Top 5 mudando só o harness, sem trocar o modelo. Um estudo da LangChain subiu 13,7 pontos no mesmo benchmark mexendo só em system prompt, ferramentas e middleware. A lição prática: quando o agente erra, o instinto é culpar o modelo — mas quase sempre a falha é uma ferramenta faltando, uma regra vaga, um guardrail ausente ou um contexto entupido de ruído. A maioria das falhas de agente são falhas de configuração.

Maestro ou orquestrador? Os dois modos do dev

O paper descreve dois modos entre os quais o dev transita. No modo maestro (conductor), você trabalha em tempo real com um par-programmer de IA, dentro da IDE, vendo o código aparecer e corrigindo a cada passo — bom pra lógica complexa, debug difícil e código desconhecido (Copilot, Gemini Code Assist, Cursor, Windsurf). O risco é virar gargalo: se você dirige cada tecla, o ganho da IA é limitado. No modo orquestrador, você opera num nível mais alto — define metas, delega a agentes que rodam em paralelo no fundo, e revisa resultados (Jules, Copilot agent mode, background agents do Cursor, Claude Code). Esse modo exige outro conjunto de habilidades: especificação, decomposição, avaliação e design de sistema. É a mesma evolução de abstração que comentei em loop engineering e níveis de abstração.

E aí entra o problema dos 80%: a IA gera rápido uns 80% do código de uma feature, mas os 20% restantes — edge cases, tratamento de erro, pontos de integração, requisitos sutis de correção — exigem conhecimento contextual profundo que os modelos ainda não têm. Pior: os erros evoluíram de sintaxe pra conceituais — suposições erradas sobre regra de negócio, falta de pedir esclarecimento, decisões de arquitetura que viram dívida silenciosa. São mais difíceis de pegar porque o código “parece certo” e até passa nos testes básicos. O dev que navega bem isso usa a IA pro que ela é boa (implementação rápida de tarefa bem-especificada) e reserva a própria atenção pro que ela sofre (ambiguidade, trade-offs, verificação).

Na prática, os agentes aparecem em três lugares — e a maioria usa os três no mesmo dia: no editor (completar inline, chat na IDE — Copilot, Cursor, Windsurf, JetBrains AI), no terminal (você larga um objetivo em linguagem natural e ele trabalha pelo código todo — Antigravity CLI, Claude Code, Codex CLI, Open Code, Cline) e no fundo (agentes que rodam horas em sandbox na nuvem e devolvem um PR — Google Jules, Copilot agent mode, background agents do Cursor, AlphaEvolve).

Quando o que você constrói é um agente

Tudo acima é usar agentes pra construir software. Mas e quando a coisa que você precisa construir é um agente — um bot de suporte que processa reembolso, um assistente de pesquisa, uma ferramenta de compliance? Isso é produto: precisa de ferramentas próprias, memória, avaliação e infra de deploy. O paper apresenta a Agents CLI do Google: uma ferramentinha de linha de comando que empacota skills pra construir agentes no Google Cloud e funciona com o coding agent que você já usa (Claude Code, Codex, etc.). Depois de um uvx google-agents-cli setup, o seu agente ganha sete skills cobrindo o ciclo do ADK: scaffolding, escrever o código do agente, avaliar, fazer deploy no Agent Runtime e ligar observabilidade. Você não aprende um SDK novo — descreve o que quer e o coding agent usa as skills.

O mesmo workflow escala de um agente pra muitos. O ADK oferece workflows baseados em grafo e multi-agente, e a coordenação acontece por estado de sessão compartilhado, pelo MCP (Model Context Protocol, pra acesso a ferramentas) e pelo protocolo A2A (Agent2Agent, pra delegação entre agentes). O exemplo que fecha a seção é o melhor: um experimento da equipe da Anthropic no começo de 2026 em que times de agentes construíram um compilador C funcional em Rust ao longo de duas semanas, com humanos definindo direção e revisando — mas não escrevendo a implementação. O gargalo migrou de escrever o código pra especificar o que ele deve fazer e verificar que os agentes fizeram.

A economia da IA: CapEx, OpEx e a conta de tokens

Essa parte é a que mais devia chegar nos líderes de engenharia. A conversa não pode parar em “quão rápido a gente coda” — o que importa é o custo total de propriedade (TCO), e no mundo da IA o OpEx é ditado pela economia de tokens. O vibe coding parece barato (CapEx quase zero, só uma assinatura mensal), mas esconde um OpEx que cresce composto: taxa de queima de tokens (despejar arquivos enormes no contexto e pedir pra IA consertar o próprio erro, com baixa taxa de acerto de primeira), imposto de manutenção (código sem consistência estrutural que vira dias de engenharia reversa seis meses depois) e remediação de segurança (geração rápida de código = geração rápida de vulnerabilidades).

O agentic engineering inverte a conta: CapEx alto, OpEx baixo. Você investe na frente — desenhar schemas de API, suítes de teste determinísticas e, principalmente, estruturar o contexto do agente — e o custo marginal de enviar e manter cada feature despenca. Por isso o paper chama o context engineering de alavanca financeira: passar um repositório de 100 mil tokens em todo prompt é inviável; um payload denso e de alto sinal (um AGENTS.md preciso, guardrails de arquitetura) aumenta a taxa de acerto de primeira e evita os loops caros de tentativa e erro. E tem o roteamento inteligente de modelo: usar modelos grandes só pro complexo (requisitos, arquitetura, implementação inicial) e rotear o determinístico (gerar teste, code review, monitorar CI/CD) pra modelos menores, mais rápidos e bem mais baratos. Economizar token é exatamente o tipo de disciplina que defendo no Caveman Mode pra economizar tokens.

Por onde começar (dev, líder e organização)

O paper fecha com playbooks por perfil. Pro dev individual: (1) monte um AGENTS.md com dez linhas (stack, convenções, regras duras, workflow) e adicione uma regra toda vez que o agente fizer algo que não devia repetir; (2) instale um conjunto de skills (tipo a Agents CLI); (3) pegue um workflow repetitivo e transforme no seu primeiro agente — construir um de ponta a ponta ensina mais que ler sobre cem; (4) escreva os testes e evals antes de gerar o código (eles são o contrato com a IA); (5) revise cada linha que vai pra produção, desconfie do que parece esperto, cheque se os imports são pacotes reais; (6) mantenha as suas skills afiadas — trate a IA como forma de aplicar expertise em escala, não como substituta dela.

Pro líder de engenharia: faça do context engineering uma prática de primeira classe (AGENTS.md, system prompts e eval suites versionados e revisados em PR como código); coloque a barra no eval, não na demo (uma demo prova que funcionou uma vez; um eval com rubrica clara prova que funciona sempre); reformule o code review pra código de IA; separe trabalho de protótipo do de produção; e invista no harness como ativo compartilhado do time. Pra organização: trate IA como investimento de engenharia e não como feature de produtividade; construa o substrato de produção (evals em CI, traces, permissões escopadas) antes de escalar; adote padrões abertos (MCP e A2A); planeje times híbridos de humanos e agentes; e contrate por julgamento, não por volume de código.

Conclusão: intenção é a nova interface

Saí dessas 51 páginas com três princípios que o próprio paper marca como duráveis, e que eu assino embaixo: (1) estrutura escala, vibe não — vibe coding serve pra exploração e protótipo, mas software de produção exige a disciplina do agentic engineering; (2) a IA amplifica a sua cultura de engenharia — times com bom teste, padrão de arquitetura e code review saudável extraem muito mais da IA, porque ela multiplica tanto a força quanto a fraqueza; (3) o papel humano está evoluindo, não diminuindo — quem entende arquitetura, especifica com precisão e avalia criticamente vale mais do que nunca. Vale ler junto com o que escrevi sobre planejamento como engenharia, porque é o mesmo espírito: pensar antes de soltar o agente.

A frase que fecha o material resume tudo: “geração está resolvida; verificação, julgamento e direção são o novo ofício”. Se você quer ler a masterclass completa do Google — com as figuras, a tabela do espectro e todas as referências — o PDF base “The New SDLC With Vibe Coding” está disponível aqui.