A crítica à teoria da inutilidade do harness engineering na big tech e ao discurso desenfreado dos loops de próxima geração

Após uma reportagem do AI Times sobre a teoria da inutilidade do harness engineering na big tech ser publicada, vários líderes de tecnologia trocaram opiniões sobre o assunto. A reportagem indicava que, após o Google, a OpenAI também afirmou que modelos de próxima geração poderiam absorver uma parte significativa das funcionalidades atuais do harness.

Este artigo complementa essa discussão. Para ir direto ao ponto: concordo com a perspectiva de que a maioria do harness se tornará obsoleta. Eu mesmo escrevi em Harness Engineering Completo — Nascimento, Conceito, Lacunas e Futuro em Uma Única Visão que harnesses complexos criados para corrigir as fraquezas dos modelos serão rapidamente substituídos conforme os modelos melhoram.

No entanto, basear-se nisso para argumentar que todo o harness logo será desnecessário é ignorar a essência do harness. O problema da absorção de funcionalidades pelo modelo é diferente do problema de humanos e organizações gerenciarem responsabilidades ao delegarem trabalho para IA.

Primeiro, devemos examinar como as palavras-chave são consumidas

No entanto, é importante verificar primeiro porque as palavras-chave tecnológicas domésticas costumam ser consumidas de forma diferente do resto do mundo. Desta vez também, precisamos separar as declarações originais, as discussões técnicas reais e os frameworks criados domesticamente.

Comparação de consumo doméstico e global do termo "harness engineering" do artigo Harness Engineering Completo — Nascimento, Conceito, Lacunas e Futuro em Uma Única Visão.

Novamente, o ponto a ser cauteloso sobre uma interpretação ampliada é que não havia evidência clara de que expressões como "harness is dead" ou "harness is useless" eram amplamente utilizadas em inglês. É mais próximo de uma discussão sobre como a capacidade de uso de ferramentas dos modelos melhora, alguns scaffoldings são absorvidos pelo modelo ou plataforma, e a vida útil de camadas complexas de orquestração construídas manualmente pode ser encurtada. As declarações do vice-presidente Noam Brown também não foram verificadas diretamente até a fonte original por mim, mas através de reportagens domésticas e internacionais. Portanto, examinarei o próprio framework de "teoria da inutilidade do harness" que se solidificou rapidamente domesticamente.

Harness que desaparecerá e harness que devem permanecer são diferentes

O harness que desaparecerá é claro. Abordagens que exigiam dividir prompts em múltiplos estágios, regras temporárias para contornar falhas de modelos específicos, fluxos de trabalho rasos que fixavam manualmente a ordem de chamadas de ferramenta — tudo isso pode ser absorvido conforme os modelos melhoram. É correto que esse harness desapareça.

No entanto, como o CEO Dong-Soo Lee da A2Sys organiza, acho arriscado estender isso para interpretar todo o harness como desnecessário. Para resumir:

• O harness de prompts e fluxos de trabalho pode ser absorvido pelos modelos. Concordo.
• O harness de execução de ferramentas lida com permissões, aprovações e recuperação de falhas. Isso realmente desaparecerá?
• O harness de runtime, memória e infraestrutura lida com contexto, cache, roteamento de modelos, custo, latência e trilhas de auditoria. Acho difícil considerar isso também como harness que desaparecerá.

O ponto central que coloco nos capítulos 7 a 11 de 『Harness Engineering: Iniciando do Zero em Engenharia de Software de IA』 também está aqui. Contratos definem intervalos permitidos, estrutura e isolamento reduzem o escopo de mudanças, e rastreabilidade e verificação vinculam objetivos originais aos resultados reais. Medição e operação gerenciam custos, permissões, falhas e recuperação. O harness engineering nesse escopo não é algo resolvido apenas porque os modelos melhoram.

Por outro lado, também é verdade argumentar que harness, loops e engenharia de prompts são heurísticas humanas. Todas as metodologias começam com heurísticas. Tipos, testes, CI, revisão de código e separação de permissões são todos métodos que humanos criaram para lidar com sistemas complexos. Mas o que importa mais aqui é: podemos confiar transparência e responsabilidade integralmente a um modelo de ponta? Se você delegou o trabalho, você não pode verificar se está sendo feito corretamente conforme sua intenção ou se a IA está causando danos além da responsabilidade. Claro, poderia haver uma IA monitorando e corrigindo isso, mas então isso seria harness.

Em um comentário em um post do Professor Han Sang-ki, escrevi essa posição assim:

Acho que depende de até que ponto você vê o harness engineering. Enquanto a intenção de organizações e desenvolvedores existir, é difícil imaginar que desapareça.

Conforme os modelos ficam mais inteligentes, há também uma possibilidade crescente de que a IA complete com mais brilhantismo algo completamente errado. É por isso que o harness não é um dispositivo de correção de fraquezas dos modelos, mas um dispositivo operacional que fixa direção e responsabilidade.

Na prática operacional, os limites de responsabilidade vêm antes da capacidade do modelo

A Nextain realiza trabalhos com clientes desenvolvedores através do Discord. E hoje, inseri um agente Claude Code que estava resolvendo um problema específico naquele canal. Um agente Nextain participando do canal Discord (na verdade Claude Code rodando em um servidor) lê o canal e responde.

Um operador não-desenvolvedor no canal forneceu resultados de testes, pontos insuficientes e requisitos. Ele começou a processar o que podia e, quando precisava modificar implantação crítica ou recursos que não devem ser tocados, pergunta por minha aprovação.

Além disso, como os solicitantes estavam frustrados porque começou a trabalhar imediatamente após ouvir os requisitos, instruí o processo de trabalho. Quando ouve requisitos, responde confirmando que ouviu, realiza análise, faz um plano, relata o plano novamente no canal Discord e prossegue com o trabalho. E finalmente, quando o trabalho é concluído, faz um relatório final e, se houver algum problema no meio do caminho, me chama como líder de desenvolvimento para fazer perguntas sobre decisões necessárias no Discord.

O núcleo deste harness é o processo de desenvolvimento da Nextain e as permissões de cada membro. Se isso fosse um modelo de ponta, faria o trabalho da melhor forma possível por conta própria? Existe realmente apenas uma melhor maneira? Consistência em processo e trabalho organizacional é, em última análise, harness. Esse limite de responsabilidade é independente da capacidade do modelo. Quanto mais coisas um modelo conseguir fazer, mais rigorosamente você precisa separar o que pode fazer e onde deve parar.

O problema no trabalho real é drift e custo

O problema que desenvolvedores usando Codex e Claude enfrentam na prática ainda é drift. Mesmo estreitando objetivos, o trabalho desvia para outros caminhos, fazem mudanças que lhes disseram para não fazer, alteram testes para passar e perdem os limites de permissões operacionais. Conforme o modelo fica mais sofisticado, esse problema pode ser ocultado mais suavemente.

Nesse momento, a resposta "apenas execute mais" é possível para big tech. Pode aumentar tempo de inferência, criar mais candidatos, descartar caminhos que falharam e adicionar validação externa. Mas desenvolvedores na prática e startups pequenos que precisam economizar cada centavo não podem fazer isso. A realidade das empresas domésticas também é a mesma.

No comentário mencionado acima com o Professor Han Sang-ki, "eficiência de custo total de tokens" mencionada pelo ex-Secretário Assessor Chefe de Planejamento de Futuro da IA Jung-Woo Ha é exatamente esse padrão. Harness não é um dispositivo que rejeita modelos de ponta. É um dispositivo de controle de custo para usar modelos caros apenas para decisões realmente necessárias e separar trabalho repetível em modelos pequenos, ferramentas locais, scripts e verificadores determinísticos.

Realizações recentes da OpenAI relacionadas a matemática também precisam ser separadas em dois momentos. Considero a primeira realização relacionada ao contraexemplo do problema de distância unitária de Erdős como descoberta de conexões matemáticas diferentes das abordagens existentes, avaliada altamente. É porque demonstra a possibilidade de novas descobertas que apenas IA poderia alcançar.

Por outro lado, computação no tempo de teste, que foi mais destacada depois, é a direção de investir mais computação, exploração de candidatos, verificação e iteração no momento da inferência. Também é uma tecnologia importante. Mas se você falar sobre isso apenas como melhoria de inteligência pura de um único modelo, a estrutura de custos desaparece. Também é tecnologia de quantidade bruta, mas é particularmente favorável para big tech.

Harness é uma linha de defesa de custo e dados

"Modelos devorarão harness" é uma frase provocante. Mas quem usa esse modelo e quanto custa é um problema separado. Conforme um modelo absorve mais funcionalidades, o código do usuário pode ficar mais simples. Ao mesmo tempo, você pode se tornar mais dependente de chamadas de modelos mais pesadas e caras. A complexidade não desaparece; ela se move do espaço de trabalho do usuário para a camada de cobrança do provedor do modelo.

Dados são iguais. Para que um agente seja realmente útil, ele precisa ver documentos, código, cronogramas, e-mails, logs operacionais, histórico de incidentes, fluxos de aprovação, dados de clientes. No momento em que o agente se torna seu espaço de trabalho, todo o seu trabalho se torna entrada.

Bom harness envia apenas o contexto necessário para o modelo externo e mantém o resto no espaço de trabalho do usuário. Ele roteia modelos, reutiliza cache, divide permissões e adiciona verificação reproduzível. É por isso que o harness é uma linha de defesa de custo e uma linha de defesa de dados.

Dessa perspectiva, há também uma possibilidade de que empresas de modelos globais se sintam incomodadas com forte harness do lado do usuário. Se o usuário primeiro processa com modelos pequenos e ferramentas locais, chamando apenas o ponta quando necessário, o volume de chamadas e contexto transmitido diminui. Na verdade, não é afirmação, mas um relacionamento de interesse que deve ser considerado naturalmente em estruturas industriais onde custos de desenvolvimento de modelos fronteiriços, inferência, GPU e energia estão crescendo.

OpenAI e Anthropic estão na linha de frente da competição de harness através de Codex e Claude Code. Por outro lado, Google é uma empresa de modelos e também é um provedor de nuvem. Embora não possamos dizer que cada empresa tenha exatamente os mesmos interesses, é claro porque essa discussão é difícil de ouvir apenas como previsão técnica pura. Bom harness reduz o desejo de big tech de "mover o espaço de trabalho para o modelo para coletar dados" e reduz a dependência de uso de ponta.

Loops não são o padrão de próxima geração

O mesmo vale para loops. Estou usando loops, mas acho que para a maioria das missões, é mais apropriado não usar loops. Se o resultado adequado pode ser alcançado mesmo se delegado a um desenvolvedor geral, provavelmente é mais barato e rápido usar um bom modelo uma vez corretamente. Surpreendentemente, os casos em que loops são eficazes são restritos.

Primeiro é pesquisa e desenvolvimento. Trabalho onde não há resposta certa, hipóteses mudam com base em resultados experimentais e os próximos experimentos devem mudar ativamente lendo os resultados anteriores. Assim é com a pesquisa de voz e música que realizamos internamente. Nesse caso, vários AIs revisam os resultados de experimentos e dados completos, julgam continuidade com experimentos anteriores, presença de drift e necessidade do próximo ciclo. O critério de conclusão não é resultado plausível, mas o julgamento de que indicadores não estão mais subindo. Como o objetivo é convergência de exploração, loops são apropriados.

Segundo é ao usar modelos pequenos em ambientes restritos. Modelos LLM pequenos tendem a reduzir objetivos e parar "isso é suficiente". Mas nesse caso, o que é necessário é menos loops longos e mais um dispositivo que fecha objetivos e condições de término. É mais próximo da funcionalidade de goal do Claude Code do que de um loop. Um harness. Se você ficar derramando loops em tarefas cotidianas de usuários gerais, isso se torna desperdício de custos. Loops são usados para convergência de exploração e harness é usado para fixar objetivos e responsabilidade. Os dois não são relacionados por substituição.

Naia quer deixar o espaço de trabalho no lado do usuário

Naia não rejeita modelos de ponta. Planejamos usar o modelo de ponta na nuvem completamente em desenvolvimento. Deve-se usar bons modelos.

Mas não temos intenção de entregar todo espaço de trabalho e dados para plataformas big tech. O que Naia busca é uma estrutura que usa juntos: local, P2P, open-weight, modelos pequenos, verificadores determinísticos e harness de permissão explícita. Use o ponta caro para decisões necessárias, mas o espaço de trabalho básico deve permanecer nas mãos do usuário.

Desse ponto de vista, avanços em modelos open-weight como DeepSeek, Qwen, Kimi, e GLM são importantes. Torna-se possível uma composição que combina modelos por propósito, protege dados localmente e chama ponta fechada apenas no momento necessário. Na Coreia, estratégias de modelos proprietários de empresas como Upstage e Naver também fazem sentido nesse fluxo. Em vez de simplesmente seguir a ponta de big tech global, pode ser mais prático encontrar uma forma de bem conectar open-weight, modelos proprietários, harness especializado e contexto de trabalho doméstico.

Você pode alugar modelos. Mas não precisa alugar seu espaço de trabalho e dados também.

Conclusão: O que é necessário além de teorias da inutilidade é discussão sobre nível técnico

Harness que desaparecerá desaparecerá. Funcionalidades que modelos absorvem aumentarão. Não há razão para negar isso. Mas não acho que funcionalidades absorvidas pelo modelo, sistemas de execução que fixam a intenção e responsabilidade organizacional, sistemas operacionais que protegem limites de custo e dados desapareçam. Se o sujeito que delega trabalho para IA é humano e o sujeito responsável pelo resultado também é humano, então contrato, estrutura, rastreabilidade, verificação e operação não desaparecem.

Espero que não tenhamos mais discursos sobre palavras-chave sobre se harness está morto ou vivo. Gostaria de ver discussões realmente centradas em tecnologia primeiro como: o que colocar dentro do modelo, o que manter sob o controle de usuários e organizações, como verificar e reverter drift, e quem arcará com custos de token e exposição de dados.

Referência e Fontes

Meus Artigos e Livro

• 『Harness Engineering: Iniciando do Zero em Engenharia de Software de IA』
• 「Harness Engineering Completo — Nascimento, Conceito, Lacunas e Futuro em Uma Única Visão」
• 「Harness Engineering」 Notícia de Publicação

Oportunidade Direta dessa Discussão

• AI Times, "Após Google, OpenAI também defende 'teoria da inutilidade do harness'... Modelos de próxima geração absorverão funcionalidades"
• AI Times, "[25 de junho] 'Modelos devorarão harness'..."
• Post do Professor Han Sang-ki no Facebook e discussão em comentários
• Dong-Soo Lee, CEO da A2Sys, "Teoria da inutilidade do harness? Metade está certa e metade está errada"

Documentos e Materiais Técnicos Originais

• OpenAI, "Learning to Reason with LLMs"
• OpenAI, "An OpenAI model has disproved a central conjecture in discrete geometry"
• OpenAI, "Introducing Codex"
• OpenAI, "Introducing OpenAI o3 and o4-mini"
• Google, "Gemini 2.0: our new AI model for the agentic era"
• "The Interplay of Harness Design and Post-Training in LLM Agents"
• "More Is Not Always Better: Cross-Component Interference in LLM Agent Scaffolding"
• "AutoHarness"