Perguntas de entrevista sobre harness engineering: 22 perguntas com respostas para engenheiros de IA

Como se preparar

As perguntas de uma entrevista de harness engineering costumam ir do geral ao específico: o que é o harness, de que partes é feito, como você diagnostica um problema, como mede o efeito de uma mudança. O entrevistador procura raciocínio de engenharia: a capacidade de separar um problema do modelo de um problema do ambiente e de propor uma solução verificável. A seguir, 22 perguntas com respostas de referência, agrupadas por tema.

Fundamentos

1. O que é o harness de um agente?

O harness é todo o ambiente em que um agente de IA opera, exceto o modelo: instruções, ferramentas, ambiente de execução, armazenamento de estado e laços de feedback. O modelo toma decisões; o harness define o que ele sabe, o que consegue fazer e como fica sabendo do resultado. O mesmo modelo, em harnesses diferentes, apresenta qualidades muito diferentes.

2. Qual é a diferença entre harness engineering, engenharia de prompt e engenharia de contexto?

A engenharia de prompt trabalha com a formulação de uma única requisição; a de contexto, com o que entra na janela do modelo em cada passo. A engenharia de harness abrange as duas e acrescenta o que não se resolve só com texto: acesso às ferramentas, ambiente reproduzível, estado entre sessões e verificação mecânica do resultado.

3. Cite os cinco subsistemas do harness.

Instruções (AGENTS.md, CLAUDE.md, skills, documentação), ferramentas (shell, testes, linter, navegador, MCP), ambiente (dependências, runtime, Docker, worktree), estado (PROGRESS.md, lista de funcionalidades, decisões) e feedback (make check, E2E, hooks, avaliador). A ausência de qualquer um não causa um «desempenho um pouco pior», e sim uma classe sistemática de falhas.

4. Por que trocar por um modelo mais forte muitas vezes não resolve?

Porque muitas falhas não têm relação com a inteligência do modelo. Um modelo mais forte não usa um comando ao qual não tem acesso, não lembra a sessão de ontem sem um arquivo de estado e não percebe que uma migration está quebrada se ninguém a executou. As convenções específicas de uma equipe também não são adivinhadas.

Diagnóstico

5. O agente violou uma regra escrita no CLAUDE.md. O que você faz?

Primeiro verifico se o agente consegue encontrar a regra: um arquivo longo, com dezenas de itens, dilui o que é importante. Reduzo o arquivo de entrada a um sumário e movo os detalhes para documentos carregados conforme a condição. Se a regra é crítica, transformo-a em uma verificação executável: uma regra de linter, um teste, um guarda grep ou um hook. Assim a violação fica visível por máquina, sem depender da atenção do modelo.

6. Como identificar pelo sintoma qual subsistema está quebrado?

Violação de convenções conhecidas indica instruções. O agente que «quer, mas não consegue» indica ferramentas. Cada sessão começar consertando o ambiente indica ambiente. Uma sessão nova que não sabe onde o trabalho parou indica estado. «Pronto» que não bate com a realidade indica feedback.

7. Por qual subsistema começar a construir o harness, e por quê?

Pelo feedback. Sem um comando que responda de forma mecânica se o resultado funciona, não é possível medir o efeito de nenhuma outra mudança. Em seguida costumam vir instruções, estado, ambiente e ferramentas, mas a ordem é empírica e depende do que está mais quebrado.

8. Como medir a contribuição de um componente específico do harness?

Com ablação: fixo o modelo e o conjunto de tarefas, desligo um subsistema por vez e observo a queda. Mas o melhor ponto de partida é um diário de falhas classificado por camadas, que aponta o gargalo mais rápido. Queda zero não significa que o componente é inútil: talvez essas tarefas não o usem ou ele seja redundante.

Instruções e contexto

9. Como estruturar um bom AGENTS.md?

Como um roteador, e não como um livro-texto: o que é o projeto, como subir o ambiente, como verificar, a definição de pronto e uma lista curta de restrições obrigatórias. Os detalhes ficam em documentos separados, referenciados com condições como «leia isto quando a tarefa envolver pagamentos». O arquivo deve definir invariantes («dados são validados na fronteira»), e não ditar implementação e bibliotecas linha por linha.

10. Para que servem os subagentes?

Para isolar o contexto. Tarefas paralelas, como busca na base de código, revisão ou verificação, rodam em um contexto próprio e devolvem apenas o resultado. A conversa principal não se polui, e o subagente verificador não herda o raciocínio do executor, o que é essencial para uma avaliação justa.

11. O que é dívida de harness?

É a divergência acumulada entre o harness e a realidade: regras obsoletas, comandos que não funcionam mais, documentos sobre módulos que não existem. Assim como a dívida técnica, ela cresce em silêncio e é paga com falhas do agente. O harness precisa de revisão periódica, e não de uma configuração feita uma única vez.

Estado e sessões

12. Como lidar com a amnésia do agente entre sessões?

Guardando o estado no repositório: PROGRESS.md (situação atual, feito, bloqueios, próximos passos), DECISIONS.md (decisão, motivo, alternativas descartadas), lista de funcionalidades com status e commits frequentes. Nas instruções, define-se o início da sessão: ler o progresso, rodar o script de verificação do ambiente e pegar a funcionalidade ativa.

13. Para que serve a regra WIP = 1?

Quando o agente começa várias funcionalidades ao mesmo tempo, o estado se dispersa: nenhuma fica pronta, as alterações se misturam e o rollback fica difícil. Uma única funcionalidade ativa dá um ponto de verificação claro, commits limpos e uma recuperação simples depois de uma falha.

14. O que é um teste de partida a frio?

É verificar se uma sessão nova, sem dicas humanas, responde às perguntas básicas: qual é o projeto, onde o trabalho parou, qual funcionalidade está ativa, como checar se tudo está bem. Se o agente responde com base nos arquivos, sem adivinhar, o subsistema de estado está funcionando.

Verificação

15. Por que testes unitários verdes não provam que a funcionalidade funciona?

Porque o teste unitário isola o módulo e substitui as dependências por mocks, e assim não enxerga as junções: incompatibilidade de interfaces, propagação de estado (o esquema mudou e o cache está antigo), vazamento de recursos e problemas de configuração e de ambiente. Os defeitos que os testes unitários pegam são um subconjunto dos que os de integração pegam, e estes são um subconjunto dos que o E2E pega.

16. O que é verification gap e como se calcula?

É a proporção de tarefas que o agente declarou concluídas e que a verificação independente não confirmou. Pegue 10 tarefas seguidas e registre esses dois fatos em cada uma. A métrica dá uma linha de base: depois de melhorar o harness, recalcule-a em um conjunto parecido de tarefas.

17. Como escrever a definição de pronto (Definition of Done) para o agente?

No AGENTS.md, como uma lista de itens verificáveis: os comandos de verificação terminam com código 0, existe um E2E cobrindo o cenário, as migrations são aplicadas, o progresso está atualizado. É útil também listar explicitamente o que não conta como pronto, como «parece correto», «os testes unitários passam» ou «funciona na minha máquina».

18. Por que o agente não deve marcar «pronto» por conta própria?

Porque modelos tendem a superestimar o próprio trabalho, e a autoavaliação acontece no mesmo contexto em que a decisão foi tomada. O status passing deve ser definido pelo script de verificação, com base nos resultados das execuções, registrando o hash do commit como evidência.

19. Como montar um avaliador independente?

Um agente ou sessão separada que vê apenas o requisito, o diff e os resultados das execuções, mas não o raciocínio do executor. Ele avalia por uma rubrica (corretude, arquitetura, testes, tratamento de erros) e cada conclusão cita arquivo, linha ou log. De preferência, usa outro modelo, para que os pontos cegos não coincidam.

20. Como tornar uma regra arquitetural executável?

Em três níveis: guarda grep (rápido, por padrão de texto), regra de linter que entende o grafo de imports (import-linter, dependency-cruiser) e teste arquitetural no CI. Todos entram no make check, falham com código de saída diferente de zero e imprimem WHY e FIX, para que o agente corrija a violação sozinho. O gatilho para uma nova verificação costuma ser o mesmo comentário aparecer na revisão pela segunda vez.

Trabalho autônomo

21. O que é preciso para deixar o agente trabalhar por horas?

Um objetivo claro, uma métrica de progresso monotônica (por exemplo, o número de funcionalidades em passing), um orçamento de tempo e de tentativas por funcionalidade, rollback automático em caso de regressão e uma lista do que exige uma pessoa: migrations, infraestrutura, dinheiro. E também isolamento: sandbox ou um git worktree separado, para que um erro não atinja o ambiente de trabalho.

22. Quando um único ciclo de agente não basta, e como desenhar o grafo de papéis?

Quando o executor passa a revisar a si mesmo e empaca. Então a tarefa é dividida em papéis: implementação, revisão, testes e merge. A revisão recebe contexto limpo e uma rubrica, e o merge acontece quando a revisão retorna pass. Se a revisão falha, a funcionalidade volta para a implementação; depois de várias falhas, ela é reiniciada com contexto limpo, o que costuma indicar um problema de entendimento da tarefa, e não do código.

Conclusão

Na entrevista de harness engineering, impressiona mais quem responde com coisas verificáveis: quais arquivos, quais comandos, qual métrica. Tenha em mente os cinco subsistemas, o verification gap e a regra de que «quem decide se está pronto é o script». Todos esses temas se juntam no curso de harness engineering, em um harness completo sobre um projeto real.