Nos últimos dois anos, os conselhos de carreira em torno dos agentes de IA giraram principalmente em torno de aprender a fazer bons prompts. Essa já não é a habilidade escassa. A habilidade escassa é construir a estrutura em que um agente opera — aquilo que cada vez mais é chamado de harness — e ela é específica o suficiente, e difícil o suficiente, para estar se tornando uma descrição de cargo própria, em vez de uma responsabilidade secundária da "pessoa de IA" de uma equipe.

O relato público mais claro do que isso realmente envolve vem da Lenny's Newsletter, que documenta como a ferramenta de gestão de produtos ChatPRD construiu um harness para depurar bugs do Sentry automaticamente. Vale a pena ler o artigo por completo se você estiver avaliando se deve se especializar nessa área, porque ele levanta um ponto fácil de passar despercebido: o modelo nunca foi o gargalo. A equipe usou o Claude Agent SDK como base e, então, dedicou a maior parte do esforço de engenharia a uma interface de terminal personalizada e a um conjunto de adaptadores conectando o agente ao Sentry, Linear, GitHub e Vercel. Esse é o trabalho, em miniatura. Quatro sistemas, quatro esquemas de autenticação diferentes, quatro formatos de dados diferentes e uma interface que permite que um humano observe e intervenha sem precisar acompanhar cada etapa.

No que o "harness" realmente se desdobra

Se você está tentando descobrir se esse é um conjunto de habilidades que vale a pena desenvolver, ajuda separá-lo em partes que são contratadas separadamente, ou pelo menos avaliadas separadamente em uma entrevista:

  • Design de permissões. Decidir o que um agente pode fazer sem supervisão (ler um chamado, esboçar um PR) versus o que precisa de um humano no processo (mesclar, implantar, excluir, gastar dinheiro) — e codificar isso como política real no código, não como uma instrução de prompt que o modelo pode ignorar sob pressão. Isso está mais próximo da engenharia de controle de acesso do que da escrita de prompts.
  • Adaptadores de ferramentas. Wrappers enxutos e bem testados em torno de cada sistema externo (Sentry, Linear, GitHub, Vercel, ou o que quer que seja a stack da sua empresa) que traduzem a intenção do agente em uma chamada de API segura e validada, e traduzem a resposta de volta em algo sobre o qual o modelo possa raciocinar. Isso é engenharia de software comum — tratamento de erros, novas tentativas, validação de esquema — aplicada a um novo consumidor.
  • Interface de terminal ou console. Uma forma de um humano ver o que o agente está fazendo, aprovar ou rejeitar ações e intervir quando ele fica travado. A ChatPRD construiu uma personalizada; muitas equipes usarão consoles de agente prontos em vez disso, mas alguém ainda precisa decidir o que é mostrado, o que fica oculto e o que exige um clique antes de acontecer.
  • Seleção de ferramentas em escala. Um artigo do Machine Learning Mastery aponta algo que vale a pena saber se você estiver construindo qualquer coisa além de uma demonstração: a precisão do agente nas chamadas de ferramentas tende a se degradar quando o catálogo de ferramentas ultrapassa cerca de uma dúzia de opções — o modelo começa a chamar ferramentas erradas, alucinar parâmetros ou travar em chamadas malsucedidas. As mitigações que ele lista (restringir quais ferramentas ficam visíveis em um determinado contexto, busca de ferramentas por recuperação, roteamento para subagentes especializados, etapas explícitas de planejamento, lógica de fallback e harnesses de benchmark para detectar regressões) são, elas próprias, uma lista de verificação de coisas que um engenheiro de harness precisa saber implementar, não apenas conhecer.
  • Engenharia de contexto e memória. A mesma fonte traça uma distinção que vale a pena internalizar: engenharia de contexto (o que entra em uma única chamada de inferência, e onde) e engenharia de memória (o que persiste entre sessões, como é armazenado, como é recuperado) são disciplinas diferentes, com modos de falha diferentes. A afirmação é que a maioria das falhas em agentes de longa duração e múltiplas sessões remonta a confundir as duas coisas — tratar a memória de sessão como se fosse apenas mais contexto, ou vice-versa — particularmente no ponto em que o sistema decide o que recuperar.

As evidências de que esse é um cargo real e financiável — não apenas um nicho de hobbistas

É razoável que os céticos perguntem se "engenheiro de harness" é um cargo ou apenas uma tarefa dentro do cargo de outra pessoa. Dois dados do compilado sugerem que a tendência é a primeira opção. Primeiro, a equipe Aspire da Microsoft — um grupo de 10 pessoas — usou os Agentic Workflows do GitHub para automatizar PRs de documentação entre repositórios e, ao longo de dois lançamentos, mesclou 82 PRs em uma mediana de 44,8 horas após o PR do produto correspondente ser lançado, sem novas contratações e sem retreinamento de processos. Essa é uma equipe pequena obtendo alavancagem desproporcional justamente porque alguém investiu na estrutura de apoio (as definições de workflow, o roteamento de revisão, a lógica de disparo) em vez de fazer os engenheiros escreverem PRs de documentação manualmente. Segundo, o projeto SkillOpt da Microsoft Research trata os arquivos de "skill" do agente — as instruções e restrições que moldam como um agente se comporta dentro do seu harness — como algo a ser otimizado sistematicamente, em vez de editado manualmente, e relata que obteve o melhor resultado, ou empatado com o melhor, em todas as 52 células de uma grade de benchmark (seis benchmarks, sete modelos, três modos de execução), com as skills otimizadas se transferindo entre modelos e harnesses diferentes. Independentemente de essa ferramenta específica se tornar padrão ou não, isso sinaliza que o setor está começando a tratar a configuração de harness como um artefato de engenharia com suas próprias ferramentas e benchmarks — a mesma trajetória que transformou o "DevOps" de um conjunto de scripts improvisados em uma disciplina.

Também está sendo construída agora uma infraestrutura explicitamente voltada para essa camada. Os recursos recém-anunciados de "Managed Agents" do Google na API do Gemini — execução em segundo plano e assíncrona, integração remota com servidores MCP, chamada de função personalizada, renovação de credenciais entre interações — são, na prática, uma canalização pronta para exatamente os problemas que a equipe da ChatPRD resolveu manualmente. Esse é um padrão normal: o que uma equipe constrói sob medida este ano, um fornecedor de plataforma transforma em produto no ano seguinte. Isso não elimina a função de engenharia de harness; eleva o piso e desloca o trabalho para integrar e configurar primitivas gerenciadas, em vez de escrever cada adaptador do zero, de forma semelhante a como a infraestrutura em nuvem não eliminou os engenheiros de operações, apenas mudou no que eles gastavam seu tempo.

O que isso significa se você está mirando nesse cargo

Algumas coisas concretas e verificáveis para colocar em um portfólio ou currículo, se você quiser ter credibilidade para esse trabalho: construa um adaptador completo, do início ao fim, contra uma API real que você não controla (incluindo autenticação, tratamento de erros e limites de taxa, não uma demonstração de caminho feliz); projete e documente um modelo de permissões para um agente que distinga ações de leitura/proposta/execução e mostre por que cada limite está onde está; e construa ou configure uma interface de revisão em que um humano aprove as ações do agente antes de elas serem executadas, já que essa é a peça que a maioria das empresas vai exigir antes de deixar um agente tocar em produção. Se você estiver avaliando uma oferta de emprego de engenharia de harness ou delimitando suas próprias responsabilidades, pergunte especificamente quem é o dono do modelo de permissões, quem é o dono dos adaptadores e quem é o dono da superfície de revisão humana — em muitas equipes, hoje, essas três coisas não têm um dono claro, que é exatamente a lacuna que esse cargo está se formando para preencher.

Uma ressalva que vale a pena declarar claramente: nenhuma das fontes acima estabelece um número de mercado de contratação para esse cargo específico, e "engenheiro de harness" ainda não é um título de cargo que você verá em anúncios de vagas — ele está aparecendo dentro de títulos como "engenheiro de infraestrutura de IA", "engenheiro de plataforma de agentes", ou simplesmente "engenheiro backend sênior, sistemas de IA". Trate isso como um conjunto de habilidades a ser construído e descrito com precisão, não como um título a ser procurado no LinkedIn.