O Arquiteto de Agentes

In partnership with

What makes a great ad in 2026?

If you want to know the core principles of high-performing advertising in 2026, join our educational webinar with award-winning creative strategist Babak Behrad and Neurons CEO & Founder Thomas Z. Ramsøy.

They’ll show you how standout campaigns capture attention, build memory, and anchor brands. You’ll walk away with clear, practical rules to apply to your next campaign.

You’ll learn how to:

• Apply neuroscientific principles to every campaign

• Build powerful branding moments into your ads

• Make your ads feel relevant to your audience

Master the art of high-impact campaigns in an era of AI-generated noise and declining attention spans

Save your seat

Acima temos o anunciante da News dessa semana  Se puder, clique no link do anunciante acima para deixar seu apoio (é grátis!) ❤️

Um cara fez 6.600 commits em janeiro. Sozinho.

Não é uma startup. Não é um time de 20 engenheiros. É um austríaco sentado em casa, de pijama, orquestrando agentes de IA.

O nome dele é Peter Steinberger. O projeto você já deve conhecer se passou na timeline do X nos últimos dias: o Clawdbot — se tornou o repositório de crescimento mais rápido da história do GitHub.

E o Peter não escreve a maior parte do código que publica.

Ele roda 5 a 10 agentes simultaneamente. Cada um trabalhando em uma feature diferente. Enquanto um implementa, outro testa, outro refatora. Peter não coda — ele arquiteta.

E quando alguém manda um Pull Request, ele nem olha o código. Ele pede o prompt que gerou o código.

A mensagem é clara: o valor migrou de quem escreve código para quem projeta sistemas onde agentes escrevem código.

Essa edição explora o que muda quando uma pessoa opera como um time inteiro — e por que a habilidade mais valiosa de 2026 não é programar, é planejar.

1⃣️ Prompt Requests > Pull Requests

Peter cunhou um termo que captura a mudança: Prompt Requests.

Na engenharia tradicional, o Pull Request é o artefato central. Você olha o diff, revisa linha por linha, comenta, aprova. O código é o que importa.

No fluxo de Peter, o código é output. O que importa é o input: qual foi o prompt, qual era o plano, qual era a intenção.

Ele conta que no Discord do projeto, ninguém discute código. Só discutem arquitetura e decisões de design.

Por quê? Porque quando agentes escrevem o código, revisar cada linha é inviável — e desnecessário. O que precisa ser impecável é a direção.

“A maioria do código de aplicação é só transformação de dados em formatos diferentes. Não merece atenção obsessiva.” — Peter Steinberger

Isso inverte a pirâmide de habilidades:

O engenheiro que ama resolver puzzles algorítmicos? Está tendo dificuldade com essa transição. Quem ama entregar produto? Está voando.

2⃣️ O Paradoxo do Planejamento

Se agentes escrevem código rápido, por que Peter gasta mais tempo planejando do que antes?

A resposta está num insight do Kieran Klaassen, que lidera o Cora na Every:

“IA nos fez desleixados porque nos fez esquecer como planejar.”

Kieran tinha 5 telas de Figma para implementar num fim de semana. O instinto era mandar o agente implementar direto. Mas ele fez o oposto: gastou 1 hora criando um agente só para planejar.

O agente analisava o screenshot do Figma, pesquisava os padrões do codebase, identificava componentes existentes, e gerava um plano detalhado.

Resultado: 5 telas pixel-perfect, incluindo layouts mobile que nem estavam no design original. Em um fim de semana.

A lição é contraintuitiva: quanto mais rápido o agente executa, mais valioso é o tempo que você investe planejando.

Kieran criou um framework de 3 Fidelidades para decidir quando planejar:

Fidelidade 1 — Quick Fix
Mudanças óbvias: bug evidente, typo, ajuste de cor. O agente resolve sem plano. Com modelos melhores, essa categoria cresce — hoje inclui reorganizar código, atualizar dependências, resolver comentários de PR.

Fidelidade 2 — O Sweet Spot ⭐
Features que cruzam múltiplos arquivos, exigem refatoração, têm escopo claro mas implementação não-óbvia. Aqui o planejamento gera ROI máximo. Complexo o suficiente pra IA errar sem guia. Simples o suficiente pra executar bem com plano.

Fidelidade 3 — Terra Incógnita
Projetos onde nem você sabe exatamente o que quer. Aqui, planejamento excessivo é desperdício. Melhor prototipar rápido e iterar.

A maioria do trabalho real está na Fidelidade 2. E é justamente onde a maioria das pessoas não planeja — porque parece “rápido o suficiente para mandar direto”.

O resultado? Horas debugando algo que 10 minutos de planejamento teriam evitado.

3⃣️ Compound Engineering: O Efeito Bola de Neve

Existe uma diferença sutil entre planejar para esta tarefa e planejar para todas as tarefas futuras.

Kieran chama isso de Compound Engineering: construir sistemas onde cada unidade de trabalho torna a próxima mais fácil.

O segredo está em como você documenta o plano.

Quando você pede para o agente “implementar feature X”, ele implementa e vai embora. Resultado: um diff no repositório.

Quando você pede para o agente “pesquisar como fazemos isso no codebase, analisar 3 abordagens com tradeoffs, e criar um plano”, algo diferente acontece:

1. O plano documenta como o time pensa

2. O agente aprende padrões do projeto

3. Na próxima tarefa similar, o agente já sabe o caminho

Código resolve problemas. Planos ensinam o sistema.

Peter faz isso instintivamente. Ele gasta um tempo surpreendente indo e voltando com o agente para refinar o plano. Desafia a abordagem. Puxa alternativas. Só quando está satisfeito, dispara a execução — e parte para o próximo plano.

É como um arquiteto que não coloca tijolo, mas garante que cada parede sustenta as próximas.

4⃣️ Por Dentro do Motor: Como Agentes de Código Realmente Funcionam

Para entender por que planejamento importa tanto, ajuda entender o que acontece por baixo do capô.

O Cursor — a IDE mais usada para coding com IA — revelou a arquitetura do seu agente, o Composer. Não é um chatbot com acesso a arquivos. É um sistema com 6 componentes:

🔀 Router — Analisa cada pedido e escolhe o modelo certo. Tarefas simples vão para modelos rápidos. Tarefas complexas vão para modelos pesados.

🧠 LLM (Modelo Agêntico) — O cérebro. Não é um LLM comum — foi treinado em trajetórias: sequências de ações que mostram como e quando usar ferramentas para resolver problemas.

🔧 Tools — Mais de 10 ferramentas: buscar no código, ler arquivos, editar, rodar comandos no terminal. O agente age no mundo real.

📚 Context Retrieval — Codebases reais são grandes demais para caber num prompt. Esse sistema busca os trechos mais relevantes para cada passo.

🎭 Orchestrator — O loop de controle. Modelo decide o próximo passo → orquestrador executa → coleta resultado → devolve ao modelo. Repete até resolver.

🔒 Sandbox — Ambiente isolado onde o agente roda builds e testes sem risco de quebrar sua máquina.

Três desafios de produção que explicam por que agentes às vezes falham:

O Problema do Diff
Quando o agente precisa editar código existente (não criar do zero), ele precisa localizar as linhas certas, preservar indentação, e gerar um diff válido. Se erra um número de linha ou desalinha a formatação, o patch quebra. Em produção, uma edição incorreta é pior que nenhuma edição.

A solução do Cursor: treinar o modelo com volume massivo de exemplos de edição — especialmente search-and-replace — para que a mecânica de editar fique gravada nos pesos do modelo.

Latência Composta
Uma tarefa pode exigir o agente planejar, buscar, editar, e testar em muitas iterações. Se cada passo leva alguns segundos, o tempo total explode.

Três técnicas que o Cursor usa:

• Mixture of Experts (MoE) — Nem todo token passa por todas as camadas. O modelo ativa só os “especialistas” relevantes.

• Speculative Decoding — Um modelo menor propõe tokens, o maior verifica. Como código tem estrutura previsível, muitos tokens são aceitos em bloco.

• Context Compaction — Resumir o estado de trabalho entre passos. Logs antigos, stack traces repetidos, diffs obsoletos — tudo comprimido para manter o prompt enxuto.

5⃣️ O Novo Perfil: O Arquiteto de Agentes

Peter não é programador no sentido tradicional. Ele é algo novo: um arquiteto de agentes.

O que isso significa na prática?

Ele mantém a estrutura do projeto inteiro na cabeça. Não o código — a arquitetura. Quais módulos existem, como se conectam, onde está a complexidade, onde está o débito técnico.

Ele projeta para extensibilidade. Uma das razões do Clawdbot crescer tão rápido é que é fácil adicionar novas capacidades. Isso não é acidente — Peter gasta energia significativa garantindo que a arquitetura permita isso.

Ele é o “ditador benevolente”. Garante que o projeto siga uma direção e estilo consistentes, mesmo com dezenas de contribuidores e agentes gerando código.

Ele prefere ferramentas que não interrompem. Peter usa Codex ao invés de Claude Code para tarefas longas, justamente porque o Codex roda em background sem pedir confirmações. Claude Code volta perguntando — o que quebra o flow quando você está gerenciando vários agentes.

Ele roda CI local, não remoto. Por quê? Porque esperar 10 minutos por um pipeline remoto é inaceitável quando você tem agentes que podem rodar os testes localmente em segundos.

A combinação dessas práticas cria algo que parece impossível: uma pessoa operando na velocidade de um time.

Mas não é mágica. É design de sistema aplicado ao próprio fluxo de trabalho.

6⃣️ As 3 Lições Para Quem Constrói Software Hoje

Olhando para Peter, Kieran, e a engenharia por trás do Cursor, três padrões emergem:

1. Use de ferramentas tem que estar nos ossos do modelo
Fazer prompt engineering para que o agente use ferramentas corretamente não é suficiente para loops longos. O modelo precisa ter aprendido como e quando usar cada ferramenta durante o treinamento. A implicação: escolha modelos treinados para agir, não só conversar.

2. Velocidade é feature de produto
Latência não é só métrica de infra — ela define se as pessoas confiam e usam o agente no dia a dia. Uma edição que demora 30 segundos é usável. Uma que demora 3 minutos é abandonada. Rotear tarefas simples para modelos rápidos enquanto reserva modelos pesados para planejamento complexo transforma responsividade em vantagem competitiva.

3. Adoção é a métrica definitiva
Benchmarks de laboratório são úteis, mas um agente de código vive ou morre pela confiança do usuário. Uma única edição arriscada ou build quebrado pode fazer o usuário abandonar a ferramenta. Avaliação tem que refletir uso real e aceitação humana — não scores em datasets.

🔮 O Shift Mental

A pergunta não é mais “como escrevo código melhor?”

É “como projeto sistemas onde agentes escrevem código melhor?”

Peter Steinberger não é produtivo porque é um programador excepcional. Ele é produtivo porque é um designer de sistemas excepcional — e hoje, o sistema inclui agentes.

O Clawdbot não cresceu porque o código é brilhante. Cresceu porque a arquitetura é brilhante — extensível, modular, projetada para que qualquer pessoa (ou agente) possa adicionar capacidades.

E o framework do Kieran mostra o caminho: pare de codificar e comece a planejar. Não porque planejar é mais nobre, mas porque cada plano ensina o sistema, e código resolve só um problema.

A engenharia de software não morreu com IA. Ela subiu de nível. O trabalho migrou de implementação para arquitetura, de execução para orquestração, de escrever para projetar.

O melhor código de 2026 não será escrito por humanos. Será projetado por eles.

🚀 Sua missão para os próximos 7 dias

1. Teste o fluxo “plano primeiro”: Na próxima feature que for implementar, gaste 15 minutos pedindo ao agente para pesquisar o codebase, propor 2-3 abordagens com tradeoffs, e criar um plano antes de escrever uma linha. Compare com seu fluxo normal.

2. Identifique sua Fidelidade 2: Liste as 3 tarefas do seu backlog que cruzam múltiplos arquivos e têm implementação não-óbvia. Essas são as que mais se beneficiam de planejamento com IA.

3. Faça um “Prompt Request”: Na próxima vez que alguém do time mandar um PR, peça para ver o prompt que gerou o código. Discuta a intenção, não o diff.

📚 Conteúdos Recomendados

🎧 Podcast: The creator of Clawd: “I ship code I don’t read” — The Pragmatic Engineer — Entrevista completa com Peter Steinberger sobre como opera como um time de uma pessoa.

📄 Artigo: Stop Coding and Start Planning — Every — O framework de 3 Fidelidades e como compound engineering transforma cada plano em investimento.

📄 Artigo: How Cursor Shipped its Coding Agent to Production — ByteByteGo — Deep dive técnico na arquitetura do Composer: MoE, speculative decoding, e sandboxing em escala.

Forte abraço,

Equipe Olympus