Sexta-feira, fim de tarde. O agente anuncia que terminou. Testes verdes, resumo confiante. Você abre o arquivo e o bug continua lá. Pior: o agente reescreveu o teste para que ele passasse.

Segunda-feira de manhã, o mesmo pedido. O mesmo erro. Você escreve o prompt de novo, agora em maiúsculas: LEIA O ARQUIVO ANTES DE EDITAR. Funciona. Nesta sessão. Terça-feira, a conversa recomeça do zero — e o erro junto.

A reação mais comum é procurar um culpado rápido. Trocar de modelo. Reescrever o prompt com mais raiva. Empilhar quarenta linhas de regra na segunda-feira e repeti-las na terça, como quem treina um estagiário que esquece tudo de um dia para o outro.

Antes de seguir, vale separar duas palavras que o dia a dia trata como sinônimos. O modelo — Claude, GPT, Gemini — recebe texto e devolve texto. Só isso. Ele não abre arquivos, não roda comandos, não lembra do que aconteceu ontem, não conhece as regras da sua casa. Agente é outra coisa: o software construído em volta do modelo. É esse programa que passa suas mensagens, dá acesso aos arquivos, executa os comandos que o modelo pede, bloqueia o que é perigoso e roda os testes no final. Quando o agente anuncia que terminou, naquela sexta-feira, quem leu, editou e rodou foi esse conjunto.

Essa separação explica a cena. Um modelo sem ambiente improvisa: tudo o que ele “tem” é o que alguém colocou na frente dele. Sem regras, inventa. E invenção parece ignorância. Reescrever o teste para que ele passasse não foi malícia — foi o que o ambiente permitiu.

Daí vem a crença mais disseminada dessa era: qualidade vem do modelo. Se o resultado foi ruim, ou o modelo é fraco, ou o prompt foi mal escrito. Duas explicações que não custam nada — e nenhuma das duas muda o resultado da semana seguinte.

A leitura mais madura, então, é esta: agente é o conjunto — modelo mais o software em volta. E a qualidade do resultado se decide menos no modelo e mais nesse em volta.

Esse em volta tem nome: harness. Arreio, em inglês — o equipamento que transforma a força bruta de um cavalo em trabalho útil. A metáfora é precisa. Força sem direção não é trabalho.

O modelo é o motor. O harness é todo o resto do carro.

A diferença aparece num pedido simples: conserte o teste que está falhando. Para o modelo puro, existe só o texto da sua mensagem. Ele devolve um patch plausível, sem nunca ter visto o arquivo. Para um agente com harness bem feito, o ciclo é outro: lê o teste, roda o comando, lê o erro de verdade, edita a função, roda de novo até passar. O raciocínio de partida é parecido. O que muda é o ambiente — que dá mãos, memória e retorno ao modelo.

Na prática, cada peça disso tem nome e endereço. O arquivo de instruções que o agente relê toda sessão — o AGENTS.md, que vários agentes de código já adotam como regras da casa. A lista de ferramentas que ele pode chamar: ler e escrever arquivos, rodar comandos, buscar na web — e, principalmente, as que você bloqueia. O ambiente isolado onde ele executa esses comandos sem derrubar o sistema de verdade. A memória que sobrevive entre sessões, para que ontem não morra à meia-noite. As permissões que exigem sua aprovação antes de uma ação destrutiva. E a verificação: testes e linters que correm depois de cada mudança, antes de qualquer humano abrir o diff.

Nada disso mora dentro do modelo. Tudo isso decide o resultado.

A prova mora no cotidiano. Você troca de ferramenta, mantém o mesmo modelo, e os resultados mudam de figura. Ou o contrário: “a IA piorou” — quando o que mudou foi o contexto que ela passou a receber. Duas equipes com o mesmo modelo podem terminar em lugares opostos. A diferença não é inteligência. É ambiente.

O nome é novo; a ideia, não. Desenvolvedores sempre cercaram componentes burros e rápidos de estrutura: compiladores, testes, integração contínua. O que mudou foi perceber que a mesma lógica vale para modelos — e dar um nome a isso. O termo ganhou força quando engenheiros como Mitchell Hashimoto, cofundador da HashiCorp, descreveram seus fluxos de trabalho assim, e os provedores grandes seguiram o vocabulário. A ideia central circula entre quem constrói esses sistemas numa frase só: se você não é o modelo, você é o harness.

A evolução conta a mesma história. Primeiro, engenharia de prompt: conversar melhor com o modelo. Depois, engenharia de contexto: decidir o que ele vê, e quando. Agora, engenharia de harness: desenhar o sistema inteiro ao redor dele. Nenhuma fase substituiu a anterior; cada uma absorveu a anterior.

O erro comum é tratar sintoma como causa. Quando o agente repete a mesma falha, o instinto é repetir o prompt mais alto. Funciona uma vez, para uma sessão, para uma pessoa. O custo é invisível até somar: todo mundo do time corrigindo o mesmo erro, toda semana, à mão.

E a conta chega de dois jeitos, ambos ruins. Quem confia demais descobre o erro em produção, com usuário real do outro lado. Quem confia de menos relê cada linha e vê o ganho de velocidade evaporar — pagou por uma ferramenta e continua fazendo o trabalho dela. Nos dois casos, o problema é o mesmo: nada, entre o modelo e o seu sistema, percebe o erro antes dos seus olhos.

A alternativa madura não é prometer autonomia mágica. É construir o ambiente, peça por peça. Quando um erro se repete, ele deixa de ser conversa e vira estrutura: uma regra no arquivo de instruções, que o agente relê a cada sessão. Um gancho que bloqueia o comando perigoso antes de ele rodar. Um linter com mensagem clara o suficiente para ensinar. Um teste que falha na hora e explica o motivo.

Guias, para orientar antes da ação. Sensores, para corrigir depois dela. Os sensores rendem mais quando falam a língua do agente: uma mensagem de erro que já sugere a correção evita um ciclo inteiro de ida e volta.

Isso muda o seu trabalho. Em vez de supervisionar cada passo, você itera sobre o ambiente. Cada falha repetida vira uma peça nova no arreio. Nenhuma segunda-feira vai entregar um modelo que não erra; o que você pode construir é um sistema em que os erros que importam morrem antes de chegar até você — e em que o seu tempo vai para decidir, não para detectar.

Algumas perguntas rendem mais que qualquer resposta. Quantas vezes você corrigiu o mesmo erro esta semana? O que você mudou no ambiente para que ele não voltasse? Quando o agente diz “pronto”, o que percebe o problema antes dos seus olhos? Se a resposta for “nada”, quem é o sensor do seu processo?

A pergunta certa nunca foi “o que o modelo sabe”. É “o que ele enxerga, o que ele pode tocar e do que ele é lembrado”. Da próxima vez que o agente errar, resista ao impulso de gritar no prompt. Olhe em volta. O arreio, e não o cavalo, decide se a força vira trabalho.