8 níveis de engenharia de agentes inteligentes

Autor: Bassim Eledath

Tradutor: Baoyu

A capacidade de programação da IA está a superar a nossa capacidade de a controlar. É por isso que todos os esforços para aumentar as pontuações no SWE-bench não estão necessariamente alinhados com os indicadores de produtividade que a liderança de engenharia realmente valoriza. A equipa da Anthropic lançou o Cowork em 10 dias, enquanto outra equipa, usando o mesmo modelo, nem conseguiu um POC (prova de conceito) — a diferença está em uma equipa que já colmou a lacuna entre capacidade e prática, e outra que ainda não.

Essa lacuna não desaparece de um dia para o outro, mas vai sendo reduzida gradualmente por níveis. São 8 níveis no total. A maioria de quem lê este artigo provavelmente já passou pelos primeiros níveis, e você deve estar ansioso por alcançar o próximo — porque cada nível ascendido representa um avanço enorme na produção, e cada melhoria na capacidade do modelo amplifica ainda mais esses ganhos.

Outro motivo importante para se preocupar é o efeito de colaboração em equipa. A sua produção depende mais do nível dos seus colegas do que imagina. Suponha que você seja um especialista nível 7; à noite, enquanto dorme, a IA de fundo já está a ajudar a criar vários PRs. Mas se o seu repositório precisar de aprovação de um colega para fazer merge, e esse colega ainda estiver no nível 2, revendo PRs manualmente, a sua produtividade fica limitada. Portanto, ajudar os colegas a subir de nível também beneficia a sua própria eficiência.

Ao conversar com várias equipas e indivíduos sobre as suas práticas de programação assistida por IA, observei a seguinte trajetória de progressão de níveis (a ordem não é rígida):

Níveis de Engenharia de IA

Nível 1 e 2: Autocompletar Tab e IDE com IA

Vou passar rapidamente por estes níveis, apenas para registro completo. Pode ignorar se desejar.

Autocompletar Tab é o ponto de partida. O GitHub Copilot iniciou esta tendência — ao pressionar Tab, o código é completado automaticamente. Muitos já esqueceram essa fase, e quem entrou recentemente na área pode até ter pulado essa etapa. É mais adequado para desenvolvedores experientes, que primeiro constroem a estrutura do código e deixam a IA preencher os detalhes.

IDEs dedicadas, como Cursor, mudaram o jogo ao conectar chat com repositórios de código, facilitando a edição entre ficheiros. Mas o limite sempre é o contexto. O modelo só consegue ajudar com o que consegue ver, e é frustrante quando não vê o contexto correto ou vê demais, incluindo informações irrelevantes.

Na maioria desses níveis, as pessoas também experimentam o modo de planeamento do seu IA: transformar uma ideia bruta numa sequência estruturada de passos, passar para o LLM, iterar várias vezes, e então executar. Funciona bem nesta fase, e é uma forma razoável de manter o controlo. Mas, nos níveis seguintes, veremos que a dependência do modo de planeamento diminui.

Nível 3: Engenharia de Contexto

Agora entramos na parte interessante. Engenharia de Contexto (Context Engineering) é uma palavra da moda em 2025, porque o modelo finalmente consegue seguir instruções razoavelmente complexas, com o contexto adequado. Contexto barulhento ou insuficiente é igualmente problemático, por isso o foco principal é aumentar a densidade de informação de cada token. “Cada token deve lutar pelo seu lugar na prompt” — essa era a máxima na altura.

A mesma informação, com menos tokens — densidade de informação é rei (Fonte: humanlayer/12-factor-agents).

Na prática, engenharia de contexto envolve mais do que a maioria pensa. Inclui prompts de sistema e ficheiros de regras (.cursorrules, CLAUDE.md), a forma como descreves as ferramentas — que o modelo lê para decidir qual usar —, gestão do histórico de diálogo para evitar que o IA se perca após muitas trocas, e a decisão de quais ferramentas expor em cada rodada, pois muitas opções podem sobrecarregar o modelo, tal como acontece com humanos.

Hoje em dia, já não se fala tanto em engenharia de contexto. A tendência é para modelos que toleram contextos mais barulhentos e ainda conseguem raciocinar em cenários mais caóticos (janelas de contexto maiores ajudam também). Mas o consumo de contexto continua importante. Nos seguintes cenários, ele pode ser um gargalo:

• Modelos menores são mais sensíveis ao contexto. Aplicações de voz, por exemplo, usam modelos menores, e o tamanho do contexto afeta a latência na primeira token, impactando a velocidade de resposta.

• Tokens consumidos por ferramentas. Protocolos como MCP (Model Context Protocol) e entrada de imagens consomem tokens rapidamente, levando ao modo de “sessão comprimida” mais cedo do que o esperado no Claude Code.

• IA com dezenas de ferramentas. O modelo gasta mais tokens a interpretar as definições das ferramentas do que a realmente executar tarefas.

De uma forma mais geral, a engenharia de contexto não desapareceu, apenas evoluiu. O foco mudou de filtrar contextos ruins para garantir que o contexto correto apareça na hora certa. Essa mudança abriu caminho para o nível 4.

Nível 4: Engenharia de Composição

A engenharia de contexto melhora a sessão atual. Engenharia de composição (Compounding Engineering, proposta por Kieran Klaassen) melhora as sessões futuras. Para mim e muitos outros, foi um ponto de viragem — percebemos que “programar por intuição” é muito mais do que fazer protótipos.

É um ciclo de “planejar, delegar, avaliar, consolidar”. Planeias tarefas, forneces contexto suficiente ao LLM para que as execute, delegas, avalias os resultados, e o mais importante: consolidas as lições aprendidas — o que funciona, o que deu errado, o padrão a seguir na próxima vez.

O poder está na etapa de “consolidar”. O LLM é sem estado. Se ontem introduziu uma dependência que tu claramente removeste, amanhã ela ainda estará lá — a menos que digas ao modelo para não fazer isso. A solução mais comum é atualizar o ficheiro de regras (CLAUDE.md ou equivalente), consolidando as lições aprendidas para sessões futuras. Mas atenção: encher o ficheiro de regras com tudo pode ser contraproducente (muita instrução é como nenhuma). Uma abordagem melhor é criar um ambiente onde o LLM possa descobrir facilmente o que é útil — por exemplo, manter um ficheiro docs/ atualizado (detalhado no nível 7).

Quem pratica engenharia de composição costuma ser muito sensível ao contexto fornecido ao LLM. Quando o modelo erra, a reação instintiva é verificar se o contexto está incompleto, e não culpar o modelo. Essa intuição torna possível os níveis 5 a 8.

Nível 5: MCP e Skills

Os níveis 3 e 4 resolvem o problema do contexto. O nível 5 resolve o problema de capacidade. MCP e skills personalizadas permitem ao seu LLM aceder a bases de dados, APIs, pipelines CI, sistemas de design, ferramentas como Playwright para testes de browser, Slack para notificações, etc. O modelo deixa de apenas pensar no código — passa a poder agir diretamente.

Há muitos bons recursos sobre MCP e skills, não vou repetir aqui. Mas alguns exemplos do que fazemos: uma skill de revisão de PRs compartilhada na equipa, que melhora iterativamente (ainda em desenvolvimento), ativada condicionalmente por sub-IA dependendo do tipo de PR; uma que verifica a segurança da integração com bases de dados; outra que faz análise de complexidade para marcar redundâncias ou engenharia excessiva; uma que avalia a saúde dos prompts para garantir conformidade com padrões da equipa. Além disso, roda linters e Ruff.

Por que investir tanto na revisão de skills? Porque, quando a IA começa a gerar PRs em massa, a revisão manual vira gargalo. Latent Space argumenta convincentemente que a revisão de código tradicional morreu. Agora, o que há é uma revisão automatizada, consistente, orientada por skills.

No que toca a MCP, uso o Braintrust MCP para que o LLM consulte logs de avaliação e faça alterações diretamente. Uso o DeepWiki MCP para que acesse documentação de qualquer repositório open source, sem precisar inserir manualmente na prompt.

Quando várias pessoas na equipa criam skills semelhantes, é importante consolidá-las num registry comum. A Block (com seus 100+ skills) criou um marketplace interno de skills, com pacotes específicos para diferentes funções e equipas. Skills e código têm o mesmo tratamento: pull requests, revisão, histórico de versões.

Outra tendência importante é o uso crescente de ferramentas CLI em vez de MCP (e cada vez mais empresas lançam as suas: Google Workspace CLI, Braintrust a preparar uma). A razão é eficiência de tokens. MCP injeta toda a definição de ferramentas na contexto a cada rodada, mesmo que o IA não as use. CLI, ao contrário, executa comandos específicos, e só a saída relevante entra na janela de contexto. Uso bastante agent-browser em vez de Playwright MCP por esse motivo.

Antes de avançar, um parêntese: os níveis 3 a 5 são a base de tudo que vem a seguir. O LLM é surpreendentemente bom em algumas tarefas, e terrível em outras. É preciso desenvolver uma intuição sobre esses limites, para poder acrescentar mais automação por cima. Se o seu contexto for barulhento, as prompts forem incompletas ou imprecisas, ou as descrições das ferramentas forem vagas, os níveis 6 a 8 só vão amplificar esses problemas.

Nível 6: Engenharia de Harness

O foguete realmente começa a decolar.

A engenharia de contexto foca no que o modelo vê. A engenharia de harness (Harness Engineering) preocupa-se em construir o ambiente completo — ferramentas, infraestrutura, ciclos de feedback — para que o IA funcione de forma confiável sem intervenção constante. Não basta um editor; é preciso um ciclo de feedback completo.

O sistema de ferramentas Codex da OpenAI — uma infraestrutura observável que permite ao IA consultar, relacionar e raciocinar sobre suas próprias saídas (Fonte: OpenAI).

A equipa da OpenAI integrou Chrome DevTools, ferramentas de observabilidade e navegação no navegador no runtime do IA, permitindo capturas de tela, automação de UI, consulta de logs, validação de correções. Com um prompt, o IA consegue reproduzir bugs, gravar vídeos, fazer reparos. Depois, valida as mudanças, envia PR, responde a revisões, faz merge — tudo com intervenção humana só quando necessário. O IA não só escreve código, mas vê o efeito do que produz e melhora iterativamente, como um humano.

A minha equipa trabalha com IA de diagnóstico de falhas técnicas via voz e chat, e criei uma ferramenta CLI chamada converse, que permite a qualquer LLM comunicar com o backend, fazer diálogos em ciclos. Depois de modificar o código, o IA testa na produção, e itera. Às vezes, esse ciclo de autoaperfeiçoamento roda horas a fio. Quando os resultados são verificáveis, é especialmente poderoso: o diálogo segue o fluxo, ou chama ferramentas específicas em situações concretas (ex: atendimento ao cliente).

O conceito central que sustenta tudo isto é o mecanismo de backpressure — um ciclo de feedback automatizado (sistema de tipos, testes, linters, ganchos pre-commit) que permite ao IA detectar e corrigir erros sem intervenção humana. Para autonomia, é preciso backpressure; sem ele, só se obtém uma máquina de produção de lixo. Isso também se aplica à segurança: o CTO da Vercel aponta que IA, código gerado e chaves de acesso devem estar em domínios de confiança diferentes, pois um ataque de injeção de prompt nos logs pode levar o IA a roubar credenciais — se tudo estiver no mesmo contexto de segurança, o risco aumenta. A fronteira de segurança é o backpressure: limita o que o IA pode fazer fora do controle.

Dois princípios que clarificam essa ideia:

• Projetar para throughput, não perfeição. Exigir perfeição em cada submissão leva a ciclos de bugs e sobreposição de correções. Melhor tolerar erros menores, fazer uma revisão final antes do lançamento. Assim fazemos com colegas humanos também.

• Restrições são melhores que instruções detalhadas. Dar passos específicos (“faça A, depois B, depois C”) está ficando ultrapassado. Na minha experiência, definir limites é mais eficaz do que listas de tarefas, pois o IA tende a focar demais na lista e ignorar o que está fora dela. Uma melhor abordagem é dizer “este é o resultado desejado, continue até passar em todos os testes”.

A outra metade do harness engineering é garantir que o IA navegue livremente no repositório, sem precisar de ti. A OpenAI recomenda manter o ficheiro AGENTS.md com cerca de 100 linhas, como índice para outros documentos estruturados, e integrar a atualização desses documentos no CI, ao invés de depender de atualizações ad hoc que rapidamente ficam desatualizadas.

Depois de tudo isso implementado, surge uma questão natural: se o IA consegue verificar seu trabalho, navegar no repositório, corrigir erros sem ti — por que ainda estás sentado na cadeira?

Um aviso: para quem está nos níveis iniciais, o que vem a seguir pode parecer ficção científica (mas guarda para depois, e volta a ler).

Nível 7: IA de Fundo (Background Agents)

Comentário: o modo de planeamento está a desaparecer.

Boris Cherny, criador do Claude Code, ainda afirma que 80% das tarefas começam por um modo de planeamento. Mas, com cada nova geração de modelos, a taxa de sucesso numa única tentativa após planeamento aumenta. Acredita-se que estamos a chegar a um ponto crítico: o modo de planeamento, como etapa de intervenção humana, vai gradualmente desaparecer. Não porque o planeamento não seja importante, mas porque o modelo já é inteligente o suficiente para planear sozinho. Mas há uma condição: só funciona se tiveres feito bem os níveis 3 a 6. Se o contexto estiver limpo, as restrições claras, as descrições das ferramentas completas, e o ciclo de feedback fechado, o modelo pode planear de forma confiável sem revisão. Caso contrário, ainda precisarás de supervisionar.

Para ser claro, o planeamento como prática geral não vai desaparecer — apenas vai mudar de forma. Para iniciantes, continua a ser uma boa porta de entrada (como nos níveis 1 e 2). Mas, para tarefas mais complexas, o “planeamento” passa a ser uma exploração: vasculhar o código, fazer protótipos no worktree, entender o espaço de soluções. E cada vez mais, essa exploração é feita por IA de fundo, sem intervenção direta.

Isso é importante porque desbloqueia o uso de IA de fundo. Se um IA consegue gerar planos confiáveis e executá-los sem tua assinatura, pode trabalhar de forma assíncrona enquanto tu fazes outras coisas. Uma mudança fundamental — de “mudo várias abas ao mesmo tempo” para “há trabalho a avançar sem mim”.

O ciclo Ralph é uma abordagem popular: um ciclo de IA autônoma, repetindo a execução de CLI de programação até que todas as tarefas do PRD estejam concluídas, cada rodada com uma nova instância com contexto atualizado. Na minha experiência, fazer o ciclo Ralph funcionar bem é difícil; qualquer descrição imprecisa ou incompleta no PRD pode prejudicar tudo. É um pouco “solta e esquece”.

É possível rodar múltiplos ciclos Ralph em paralelo, mas quanto mais, mais tempo se gasta em coordenação, agendamento, revisão de saídas, acompanhamento do progresso. Você deixa de programar — vira um gestor intermediário. Precisa de um orquestrador de IA para agendar tarefas, assim pode focar na intenção, não na logística.

Dispatch, que inicia 5 workers em paralelo em 3 modelos, mantém sua sessão enxuta e a IA trabalha de forma eficiente.

Recentemente, uso bastante o Dispatch, uma skill que criei para Claude Code, que transforma sua sessão numa central de comando. Você fica numa sessão limpa, enquanto workers, em contextos isolados, fazem o trabalho pesado. O orquestrador planeja, delega, acompanha. Sua janela principal fica livre para coordenação. Quando um worker trava, ele lança uma questão de esclarecimento, não falha silenciosamente.

O Dispatch roda localmente, ideal para desenvolvimento rápido, com feedback ágil, sem infraestrutura complexa. O Inspect do Ramp é uma solução complementar, para tarefas mais longas e autônomas: cada sessão roda numa VM na nuvem, com ambiente completo. Se um PM encontra um bug na UI, marca no Slack, e o Inspect assume, resolve, e faz o que for preciso — mesmo quando fecha o portátil. Custa mais em termos de infraestrutura, mas oferece escala e reprodutibilidade que IA local não consegue. Recomendo usar ambos.

Nível avançado: usar diferentes modelos para tarefas diferentes. As melhores equipas não são compostas por clones. Cada membro tem diferentes formas de pensar, background, vantagens. O mesmo se aplica aos LLMs: modelos treinados de formas distintas, com personalidades diferentes. Costumo atribuir Opus a tarefas de implementação, Gemini a exploração, Codex a revisão — uma combinação que produz resultados melhores do que qualquer modelo isolado. É uma espécie de inteligência coletiva aplicada ao código.

Importante: separar quem implementa de quem avalia. Se um mesmo modelo faz tudo, tende a ser tendencioso, a ignorar problemas, a dizer que tudo está bem quando não está. Não é por mal, é como dar a si próprio uma nota. Melhor usar um modelo diferente, ou uma instância com prompts de revisão, para fazer a avaliação. Assim, a qualidade do sinal melhora bastante.

IA de fundo também abre portas para a integração de CI com IA. Quando um IA consegue operar sem intervenção, pode disparar tarefas a partir da infraestrutura existente. Um bot de documentação, por exemplo, que gera documentação após cada merge, enviando PRs para atualizar o CLAUDE.md (que usamos), poupando tempo. Um bot de segurança que revisa PRs e faz correções. Um bot de dependências que não só identifica problemas, mas atualiza pacotes e roda testes. Com um bom contexto, regras consolidadas, ferramentas automatizadas e ciclos de feedback, tudo funciona de forma autônoma.

Nível 8: Equipa de IA Autônoma

Ainda ninguém domina verdadeiramente este nível, embora alguns estejam a avançar para lá. É o estado da arte.

No nível 7, há uma orquestração centralizada: um IA principal distribui tarefas a outros. No nível 8, essa centralização desaparece. Os próprios IA coordenam-se, assumem tarefas, partilham descobertas, resolvem dependências e conflitos — tudo sem um orquestrador único.

O recurso experimental de Equipes de Agentes do Claude Code é um exemplo: múltiplas instâncias a trabalhar em paralelo no mesmo código, comunicando-se diretamente. A Anthropic criou um compilador Linux em C com 16 IA paralelos. Cursor rodou centenas de IA em paralelo por semanas, construindo um navegador do zero, migrando de Solid para React.

Porém, há problemas. Sem uma hierarquia, os IA tendem a hesitar, a rodar em círculos. As tentativas de coordenação ainda não atingiram o ideal. Muitos dizem que a coordenação multi-IA é uma questão difícil, e ninguém encontrou uma solução definitiva.

Na minha opinião, a maioria das tarefas ainda não está pronta para esse grau de autonomia. Mesmo os mais inteligentes, para projetos complexos como compiladores ou navegadores, ainda são lentos, consomem muitos tokens, e não são economicamente viáveis. Para o trabalho diário, o nível 7 é o limite real. Não me surpreenderia se o nível 8 se tornasse padrão no futuro, mas por agora, foco no nível 7 — a menos que seja Cursor, cujo negócio é justamente ultrapassar limites.

Nível ? (futuro)

A questão inevitável de “e depois?”

Se consegue orquestrar uma equipa de IA sem dificuldades, por que limitar-se ao texto? A próxima etapa natural é a interação por voz — entre IA e IA, ou até pensamento a pensamento? Uma conversa com Claude Code, descrevendo mudanças em voz alta, e vê-las acontecer diante de ti.

Há quem busque uma geração única perfeita: dizer o que quer, e a IA fazer tudo de uma vez. Mas esse pressuposto é que sabemos exatamente o que queremos. E não sabemos. Nunca soubemos. O desenvolvimento de software sempre foi iterativo, e sempre será. Só que será muito mais fácil, muito mais rápido, e muito além do texto.

Então, em que nível estás? O que fazes para chegar ao próximo?