Addy Osmani: seu agente é 10% modelo e 90% entorno

Addy Osmani é engenheiro do Chrome no Google há mais de uma década e escreveu alguns dos livros que formaram uma geração de gente de frontend. Ele coescreveu, com Shubham Saboo e Sokratis Kartakis, o whitepaper "The New SDLC With Vibe Coding", que o Google publicou nesta semana. E aí fez algo que quase ninguém faz com o próprio paper: publicou no blog dele um texto dizendo, na prática, "não leia tudo, aqui está o punhado de ideias que realmente importa".

A ideia que ele diz não conseguir parar de voltar é uma frase de nove palavras: um agente é um modelo mais um harness.

O que sobra depois que você tira o modelo

O harness é todo o resto. Osmani lista: os arquivos de instrução e regra, as ferramentas e servidores MCP, os sandboxes onde o agente roda, a lógica de orquestração que cria subagentes e roteia entre modelos, os hooks que rodam código determinístico em pontos definidos, e a observabilidade que te avisa quando ele começou a desviar.

A divisão aproximada do paper é 10% modelo e 90% harness. Osmani reconhece que parece exagero: "soa alto até você ter passado uma semana depurando um".

E ele traz dois números públicos para tirar isso do campo da opinião. No Terminal Bench 2.0, um time tirou um agente de código de fora do top 30 e colocou no top 5 mudando apenas o harness, com o mesmo modelo por baixo. Num experimento separado, a LangChain ganhou 13,7 pontos no mesmo benchmark mexendo só em prompt de sistema, ferramentas e middleware ao redor de um modelo fixo. Nenhum dos dois tocou no modelo.

A conclusão operacional dele é a parte útil:

Então, quando um agente faz algo burro, aprendi a depurar o harness primeiro. Normalmente é uma ferramenta que falta, uma regra que escrevi de forma frouxa demais, uma proteção que esqueci, ou uma janela de contexto cheia de lixo. A maioria das falhas de agente é falha de configuração.

E ele completa com o motivo de achar isso animador: configuração é a parte que dá para consertar hoje, sem esperar modelo melhor. Aliás, o modelo vai ser trocado por baixo do harness cedo ou tarde de qualquer jeito.

É a mesma paisagem que Martin Fowler descreveu vindo do retiro da Thoughtworks, chegando por outro caminho. Quando duas pessoas com esse currículo, olhando dados diferentes, param no mesmo lugar, geralmente o lugar é real.

Contexto é decisão de arquitetura, e aparece na fatura

O botão mais importante dentro do harness, para Osmani, é engenharia de contexto. E a decisão que aparece na sua conta é o que fica em contexto estático e o que fica em dinâmico.

Estático é carregado a cada turno: instrução de sistema, arquivos de regra (AGENTS.md, CLAUDE.md, GEMINI.md), memória global, guardrails principais. É confiável e é caro, porque você paga em toda chamada. Dinâmico é carregado sob demanda: skills que disparam quando a tarefa casa, resultado de ferramenta, documento vindo de RAG. Você paga só o que a tarefa toca.

Erre para um lado e você queima token e enterra o sinal. Erre para o outro e o agente esquece as regras que o mantêm seguro. A recomendação dele é direta: trate essa fronteira como decisão de arquitetura de verdade, revisada em pull request e versionada como código.

O truque que faz o dinâmico escalar é skill com divulgação progressiva. O agente vê um pouco de metadado na largada, carrega a instrução completa quando a tarefa casa, e só puxa o material de referência pesado quando de fato precisa. É assim que um agente carrega dezenas de skills e paga só pela que está usando.

E a consequência para quem assina o cartão: roteamento e contexto são alavancas financeiras, não só técnicas. Osmani é explícito, mande o raciocínio difícil para o modelo grande e o trabalho de rotina, geração de teste, revisão de código, checagem de CI, para um pequeno e barato. A qualidade se segura e a conta cai.

A régua vai no eval, não na demo

A frase que ele diz que entregaria a um líder se só pudesse entregar uma:

Coloque a régua no eval, não na demo.

O raciocínio: demo mostra que o agente funcionou uma vez. Uma suíte de avaliação com rubrica de verdade mostra que ele funciona de forma confiável. E ele separa dois mecanismos que a maioria dos times confunde. Teste cobre a parte determinística: esta entrada, aquela saída. Eval cobre o que não é determinístico, e aí o paper faz uma distinção que vale anotar: avaliação de saída pergunta se o resultado final está certo; avaliação de trajetória pergunta se o caminho, as chamadas de ferramenta e o raciocínio, foi sólido.

Você quer os dois. Nas palavras dele, uma resposta que parece certa mas pulou as verificações é mais perigosa que uma que está obviamente quebrada.

O ciclo comprime torto, e é aí que mora o prazo

A parte mais desconfortável do texto é o mapa de fases. IA comprime o ciclo, mas comprime de forma desigual, e Osmani diz que a desigualdade é a história inteira. Implementação cai de semanas para horas. Requisito, arquitetura e verificação continuam lentos, porque são trabalho de julgamento. Resultado: qualidade de especificação vira o gargalo, e verificação se muda para o meio.

Sobre implementação, ele é honesto de um jeito raro em texto de fornecedor. Pesquisas colocam o ganho entre 25% e 39%. Um estudo da METR achou desenvolvedores experientes 19% mais lentos em algumas tarefas quando você conta o tempo gasto conferindo e consertando. E ele diz: os dois são verdade. "O resumo honesto é que a IA transforma implementação de escrever em revisar."

Se isso te soou familiar, é porque Archana Rao e Gaurav Savla publicaram no dia seguinte, no mesmo O'Reilly Radar, um texto chamado "Coding Was Never a Bottleneck" chegando na mesma conclusão pelo lado da medição: os gargalos de entrega nunca foram escrever código, eram decisão de produto, review, QA, compliance e release. Acelerar a codificação só empilha trabalho em progresso contra os mesmos afunilamentos. É Teoria das Restrições com dados de CI.

A fase que Osmani acha mais subestimada é manutenção. Código que era "arriscado demais para tocar" porque só os autores entendiam agora pode ser lido, refatorado e modernizado por um agente. As migrações e limpezas de depreciação que nunca aconteceram porque eram tediosas e arriscadas começam a acontecer. E o teto de tudo isso continua sendo o problema dos 80%: o agente pega os primeiros 80% de uma feature rápido, e os últimos 20%, os casos de borda e as costuras entre sistemas, ainda pedem contexto que o modelo geralmente não tem.

A linha de fechamento

Osmani encerra com a frase que resume o ano:

IA amplifica a cultura de engenharia onde ela cai, as partes boas e as ruins. Geração está basicamente resolvida. O trabalho que sobrou é especificação e verificação, e os sistemas que seguram os dois. É nessa parte que eu ficaria bom.

Para quem lidera time no Brasil, a tradução prática cabe em uma reunião. Pegue o agente que mais te frustra hoje e, antes de trocar o modelo, faça o inventário do harness dele: quais ferramentas ele tem, o que está em contexto estático, o que dispara sob demanda, o que roda determinístico, e como você sabe que ele desviou. Se você não consegue responder essas cinco, o problema não é o modelo. Nunca foi.

Se quiser ajuda para desenhar o harness e a suíte de eval do seu time, fala com a gente no WhatsApp.