Todos falam sobre modelos de IA.
Ninguém fala sobre a camada que realmente os torna úteis.
Claude Code. Codex. Cursor.
Estes não são apenas modelos.
São modelos envoltos em um sistema.
Esse sistema é chamado de harness.
E os melhores harnesses agora se aprimoram sozinhos.
Aqui está tudo o que você precisa entender sobre a nova pilha de IA.
A mentira que todos acreditam sobre produtos de IA

A maioria das pessoas pensa que progresso em IA = modelos mais inteligentes.
Não é.
O modelo é uma parte da pilha.
A arquitetura é publicada. Todos copiam o mesmo transformer. Todos os laboratórios usam os mesmos blocos de construção.
O que realmente separa o Claude Code de um projeto de fim de semana não é o modelo.
É o que envolve o modelo.
O harness.
Em 2017, o progresso da IA era sobre mecanismos de atenção. Em 2020, era sobre escala. Em 2026, é sobre engenharia de harness.
E os harnesses agora estão sendo projetados por IA, não por humanos.
O que é um *harness*?

Um harness é o sistema que envolve um modelo.
Ele decide:
→ Como o modelo pensa e planeja
→ Quando ele chama ferramentas e o que faz com os resultados
→ O que ele lembra entre as etapas
→ Como ele armazena artefatos e gerencia o estado
→ Como ele avalia sua própria saída
→ Quando ele volta e tenta novamente
Pense nele como um sistema operacional.
O modelo é a CPU. O harness é o SO.
Você pode ter uma CPU poderosa e um software terrível e não entregar nada útil. Você pode ter uma CPU modesta e um software excelente e entregar algo grandioso.
Os agentes de codificação mais bem-sucedidos — Claude Code, Codex, Cursor — todos têm a mesma percepção:
O *loop* importa tanto quanto o modelo.
Os 3 padrões de *harness* que todo construtor de IA precisa
Todo sistema de IA em produção usa pelo menos um destes.
Padrão 1: O *Loop

O modelo não responde uma vez e para.
Ele faz um loop.
Planejar → Executar → Observar → Melhorar → Repetir
Este é o núcleo de todo agente de codificação.
Um loop simplificado do Claude Code:
- Ler a tarefa
- Planejar a abordagem
- Escrever código → executá-lo
- Ver o que falhou
- Corrigir
- Executar novamente
- Repetir até os testes passarem
O modelo não é mais inteligente no loop 3 do que no loop 1.
Mas o sistema é.
Cada loop dá ao modelo um novo contexto — mensagens de erro, resultados de testes, rastros de execução.
A saída do loop 1 torna-se a entrada do loop 2.
Esse contexto composto é o motivo pelo qual sistemas agentivos superam prompts únicos em tarefas complexas.
A percepção chave: O modelo permanece fixo. O contexto fica mais inteligente.
Padrão 2: Sistema de Arquivos como Memória

A maioria dos desenvolvedores coloca tudo na janela de contexto.
Isto é uma armadilha.
Tarefas de longo prazo geram:
→ Registros de experimentos
→ Diffs de código → Rastros de erro
→ Históricos de rollouts passados → Resumos de artigos → Artefatos intermediários
Tudo isso cresce muito além de qualquer janela de contexto.
A solução: escrever em arquivos, não no contexto.
1# Ruim: tudo no contexto2context = saída_anterior + resultado_ferramenta + log_erro + historico...3# Explode na etapa 4745# Bom: use o sistema de arquivos6agente.escrever("experimentos/execucao_3/log_erro.txt", rastro_erro)7agente.escrever("experimentos/execucao_3/resultados.json", metricas)89# Depois, o agente lê apenas o que precisa10relevante = agente.ler("experimentos/execucao_3/resultados.json")
Isso muda tudo sobre tarefas de longo prazo.
→ O agente pode retomar após falhas
→ O agente pode raciocinar sobre seu próprio histórico de execução
→ O contexto permanece limpo mesmo na etapa 200
→ Múltiplos subagentes podem compartilhar estado via arquivos
Os melhores agentes tratam o sistema de arquivos como um segundo cérebro.
Não um depósito. Uma memória estruturada.
Padrão 3: Subagentes

Um agente não consegue fazer tudo.
Os melhores sistemas geram subagentes paralelos.
O agente pai:
→ Divide a tarefa em subtarefas independentes
→ Lança subagentes para executá-las em paralelo
→ Monitora o status deles → Mescla os resultados de volta
Exemplo para um harness de pesquisa:
1Agente pai recebe: "Escreva um relatório completo de análise competitiva"23Gera 4 subagentes simultaneamente:4→ Subagente 1: Pesquisar preços e recursos do Concorrente A5→ Subagente 2: Pesquisar preços e recursos do Concorrente B6→ Subagente 3: Buscar notícias recentes sobre ambos os concorrentes7→ Subagente 4: Coletar avaliações de usuários no Reddit e na App Store89Agente pai espera, então mescla todas as 4 saídas no relatório final1011Tempo total: o mesmo que o subagente mais lento (não 4x mais)
A regra chave de design: as saídas dos subagentes devem ir para arquivos.
Não contexto transitório. Arquivos.
Se elas viverem apenas no contexto, desaparecem quando a sessão do subagente termina.
Se viverem em arquivos, o agente pai pode inspecioná-las, o sistema pode se recuperar de falhas e tudo é auditável.
Ferramentas que todo agente de codificação usa
Se você está construindo um agente, este é o kit de ferramentas que todo grande agente de codificação padroniza.
1Ferramentas de Sistema de Arquivos:2→ glob, grep, ls # encontrar arquivos3→ read, read_many # ler conteúdo4→ write # criar novo arquivo5→ edit # editar por substituição de string6→ apply_patch # diff estruturado78Ferramentas de Shell:9→ bash # executar qualquer comando10→ PowerShell # equivalente no Windows1112Controle de Versão:13→ git_status, git_diff # inspecionar alterações14→ git_commit # salvar progresso1516Gerenciamento de Agentes:17→ spawn_agent # lançar subagente18→ wait_agent # aguardar resultado19→ list_agents # ver o que está rodando20→ interrupt_agent # cancelar se necessário2122Contexto Externo:23→ web_search, web_fetch # obter informações atuais24→ Ferramentas MCP # conectar a serviços externos
Você não precisa de todas estas para cada agente.
Mas todo agente de produção eventualmente precisa da maioria delas.
As que mais importam no início: bash, read, write, edit.
Domine essas quatro e você poderá construir quase tudo.
Engenharia de contexto: a habilidade da qual ninguém fala

O modelo é fixo.
Você não pode alterar seus pesos em tempo de execução.
Mas você pode alterar o que ele vê.
Isso é engenharia de contexto.
E é agora uma das habilidades de maior alavancagem na engenharia de IA.
Contexto ruim:
→ Despejar tudo → torcer pelo melhor
→ Contexto incha → modelo perde o foco → saídas degradam
Contexto bom:
→ Estruturado. Conciso. Em evolução.
→ Informação certa na etapa certa.
→ Falhas anteriores informam a tentativa atual.
A abordagem de ponta (ACE — Engenharia de Contexto Agentiva):
13 componentes:23Gerador: executa a tarefa, referencia um manual de contexto estruturado4Refletor: analisa sucessos e falhas, destila insights5Curador: atualiza o manual com novos aprendizados — adiciona, remove, deduplica67O manual NÃO é um bloco de prompt.8É uma lista estruturada de pares (identificador, insight).910Exemplo:11{12 "id": "001",13 "insight": "Sempre escreva rastros de erro em arquivo antes de tentar novamente."14},15{16 "id": "002",17 "insight": "Subagente para busca na web retorna melhores resultados com consultas específicas do site."18},19{20 "id": "003",21 "insight": "Executar testes antes de commitar detecta 80% das regressões."22}
O manual é atualizado após cada execução.
O agente que executa a tarefa 50 está trabalhando com 49 execuções de aprendizados destilados.
O agente que executa a tarefa 1 não tinha nada.
É assim que um sistema fica mais inteligente sem tocar nos pesos do modelo.
O *harness* que se aprimora sozinho

É aqui que fica interessante.
E se o próprio harness fosse a coisa sendo otimizada?
Não o prompt. Não o modelo.
O código que executa o agente.
Isto é exatamente o que o Self-Harness faz.
Loop de 3 etapas:
Etapa 1 — Minerar fraquezas
Execute o harness atual em um conjunto de tarefas. Colete rastros de falha. Agrupe falhas por causa raiz.
Não "falhou." Mas por que falhou.
Tipos de falha descobertos:
→ "Agente expira em leituras de arquivo longas"
→ "Saídas de subagente perdidas quando o pai falha"
→ "Mensagens de erro não são informativas o suficiente para autocorreção"
→ "Contexto cresce demais após a etapa 30, modelo perde o foco"
Etapa 2 — Propor correções
O mesmo modelo analisa os padrões de falha. Propõe edições específicas e estreitas no código do harness.
Não reescritas. Edições direcionadas.
Edição proposta no harness:
→ Adicionar manipulador de timeout às operações de leitura de arquivo
→ Descarregar automaticamente a saída do subagente para o disco a cada etapa (não apenas no final)
→ Padronizar o formato da mensagem de erro para incluir: etapa, ferramenta, entrada, saída, motivo da falha
→ Adicionar etapa de compressão de contexto a cada 25 turnos
Etapa 3 — Validar e mesclar
Cada edição proposta é testada em tarefas separadas.
Ela corrige a fraqueza sem quebrar nada?
Se sim: mesclada no harness. Se não: registrada, rejeitada, harness inalterado.
O resultado: o *harness* melhora a cada geração.
Claude 3.5 Sonnet executando Self-Harness foi de 20% para 50% no SWE-bench Verified.
Não por um modelo melhor.
Por um sistema melhor.
Busca evolutiva de *harness
Self-Harness corrige um harness iterativamente.
AlphaEvolve executa uma população de harnesses e evolui os melhores.
O algoritmo:
11. Comece com um conjunto de candidatos a *harness*22. Pontue cada um em tarefas de benchmark33. Selecione os de melhor desempenho como "pais"44. Peça ao modelo para propor diffs/melhorias55. Gere novos *harnesses* "filhos"66. Pontue os filhos77. Mantenha os que melhoram88. Adicione-os de volta ao conjunto99. Repita1011(Mesma lógica da seleção natural. Aplicada ao código.)
(Mesma lógica da seleção natural. Aplicada ao código.)
Um detalhe chave de design do AlphaEvolve:
Regiões de código elegíveis para evolução são explicitamente marcadas:
1# EVOLVE-BLOCK-START2def planejar_proximo_passo(contexto, ferramentas):3 # Esta seção pode ser modificada pela busca evolutiva4 prompt = f"Dado: {contexto}\nFerramentas disponíveis: {ferramentas}\nPróxima ação:"5 return llm.gerar(prompt)6# EVOLVE-BLOCK-END78# O resto do *harness* permanece fixo9def executar_ferramenta(nome_ferramenta, args):10 return registro_ferramentas[nome_ferramenta](**args)
Esse confinamento impede que o agente modifique acidentalmente código crítico de segurança.
A busca evolutiva só toca no que você explicitamente permite que ela toque.
AlphaEvolve usou isso para otimizar algoritmos de multiplicação de matrizes.
O resultado: superou o código otimizado manualmente do DeepMind.
O agente encontrou soluções que engenheiros humanos não descobriram em décadas.
Máquina de Gödel Darwin: agentes que se reescrevem

A versão mais extrema desta ideia.
Um agente que modifica seu próprio código de harness para melhorar em tarefas.
Máquina de Gödel Darwin (DGM):
11. Comece com um agente de codificação no conjunto22. Execute-o em benchmarks, colete pontuações33. Agente examina seus próprios logs de avaliação44. Agente propõe melhorias em seu próprio código de *harness*55. Ferramentas disponíveis: bash + editor de arquivos (ver/criar/editar arquivos)66. Nova versão do agente é criada77. Nova versão é pontuada88. Se melhor: adicionada ao conjunto99. Se pior: descartada1010. Repita — selecionando pais por desempenho, inversamente pelo número de descendentes
Condição inicial: Claude 3.5 Sonnet + harness inicial simples.
Resultado:
→ SWE-bench Verified: 20% → 50%
→ Benchmark de codificação poliglota: 14,2% → 30,7%
Zero alterações nos pesos do modelo. Zero engenharia humana entre gerações.
O agente projetou versões melhores de si mesmo.
Isto não é ficção científica.
Isto é um artigo de 2025.
5 modos de falha a evitar
Estas são as maneiras como equipes de pesquisa reais falharam.
Todas documentadas. Todas evitáveis.
1. Colapso de contexto
Tarefas de longo prazo perdem detalhes críticos se os logs não forem escritos como artefatos persistentes.
Correção: escreva tudo que é importante em arquivos. Nunca confie apenas no contexto após a etapa 20.
2. Desvio de implementação
Quando a tarefa fica tecnicamente difícil, o modelo se desvia para soluções mais fáceis e comuns em vez do objetivo real.
Correção: escreva um arquivo de especificação no início. O agente verifica a especificação em cada loop.
3. Otimismo excessivo
O modelo declara sucesso apesar de experimentos falhos.
Ele encontra "fita adesiva numérica" — correções que fazem as métricas parecerem boas sem resolver o problema real.
Correção: separe um conjunto de teste que o agente nunca vê. Valide apenas em dados separados.
4. Hackeamento de recompensa
O agente otimiza qualquer sinal que recebe.
Se o sinal são testes unitários — ele escreve testes que sempre passam. Se o sinal é um modelo juiz — ele aprende truques para enganar o juiz. Se o sinal é a pontuação do benchmark — ele explora artefatos do benchmark.
Correção: o avaliador vive fora do loop. Revisão humana em pontos chave de decisão.
5. Colapso de diversidade
Loops evolutivos convergem para uma estratégia.
Cada geração parece uma variante da mesma solução.
Correção: acompanhe explicitamente a novidade. Penalize soluções muito semelhantes aos membros existentes do conjunto (similaridade de cosseno baseada em embedding funciona).
A nova pilha de IA em português claro

Isto é o que você está realmente construindo quando constrói produtos sérios de IA:
Camada 1 — O Modelo
Inteligência bruta. Pré-treinado. Pesos fixos em tempo de execução.
Esta é a CPU. Poderosa, mas passiva.
Camada 2 — O *Harness*
O SO. Envolve o modelo. Orquestra tudo.
→ Ferramentas (bash, leitura/escrita de arquivos, busca na web)
→ Memória (sistema de arquivos, logs estruturados)
→ Loop (planejar → executar → avaliar → tentar novamente) → Subagentes (execução paralela)
→ Gerenciamento de contexto (o que o modelo vê em cada etapa)
Camada 3 — O Otimizador
O harness que melhora o harness.
→ Minera padrões de falha a partir de rastros de execução
→ Propõe edições direcionadas ao código do harness → Valida em tarefas separadas
→ Mescla melhorias, descarta regressões
Camada 4 — O Avaliador
Vive fora de todas as outras camadas.
→ Pontuações de benchmark → Revisão humana em pontos chave de decisão → Conjuntos de teste separados que o otimizador nunca toca
Você não pode pular nenhuma camada.
Pule a Camada 2 — seu modelo é um chatbot, não um produto.
Pule a Camada 3 — seu sistema nunca melhora sem engenharia manual.
Pule a Camada 4 — seu agente otimiza a coisa errada e você não vai notar.
O que isto significa para construtores agora
Você não precisa construir um harness auto-melhorável para se beneficiar destas ideias.
Comece aqui:
Semana 1: Construa o *loop*
Pare de construir prompts únicos. Construa um loop planejar → executar → avaliar → tentar novamente para qualquer tarefa que exija mais de um passo.
Semana 2: Adicione memória persistente
Pare de confiar no contexto. Escreva saídas intermediárias em arquivos. Deixe o agente ler seu próprio trabalho anterior.
Semana 3: Adicione subagentes
Identifique qualquer parte do seu fluxo de trabalho que possa ser executada em paralelo. Gere subagentes. Escreva as saídas deles em arquivos. Mescle.
Semana 4: Adicione engenharia de contexto
Acompanhe quais padrões levam ao sucesso e à falha. Construa um manual estruturado simples que se atualiza após cada execução.
Esse é o harness.
Não o modelo.
O modelo já está lá.
O harness é o que você constrói.
A verdade desconfortável sobre IA em 2026
A aceleração da pesquisa nos laboratórios de fronteira aumentou drasticamente.
Anthropic e OpenAI estão lançando mais rápido do que nunca.
Não porque os modelos ficaram mais inteligentes da noite para o dia.
Porque os harnesses melhoraram.
Um agente que faz loop, lembra, subdelega e se autocorrige supera um modelo mais inteligente usado incorretamente.
O fosso não é o modelo.
O fosso é o sistema.
E o sistema agora pode se aprimorar sozinho.
Se isto foi útil:
→ Compartilhe — todo construtor de IA precisa entender esta pilha
→ Siga @sairahul1 para mais análises como esta
→ Salve — a pilha de 4 camadas por si só vale a pena guardar
Inscreva-se em theaibuilders.co para mais artigos interessantes como este
Eu escrevo sobre IA, construção de produtos e sistemas que funcionam sem você.





