Harness está na moda — mas as pessoas não entenderam quem é realmente o seu alvo

Palo Alto, de manhã. O café acabou de ser servido. Alan Walker baixa a cabeça e vai ao encontro de um artigo da Anthropic sobre harness; ao levantar a cabeça, disse apenas uma frase:

“Há muita gente que acha que é porque o modelo melhorou um bocadinho. Estão errados. Isto é o processo a começar a trair os humanos.”

Este artigo, à superfície, fala de design de engenharia, fala de planner, generator e evaluator, fala de como fazer o Claude correr durante horas seguidas, e de como fazer produtos mais complexos.

A maioria das pessoas chega aqui e pára. Acham que:

Ah, afinal é só que o agent fica mais complexo, o prompt fica maior e o workflow fica mais detalhado.

Mas Alan diz que o que realmente vale a pena ver nunca é a funcionalidade na camada de cima, e sim para onde a autoridade está a ser transferida.

Para transformar uma tarefa complexa num resultado feito, no passado era preciso que alguém desmantelasse os requisitos, alguém executasse, alguém verificasse, alguém corrigisse ao voltar atrás e alguém assegurasse o que falhasse.

Agora, o que a Anthropic está a fazer não é tornar o modelo mais parecido com um empregado inteligente; é fazer com que todo o sistema comece a assumir a camada de organização, a camada de supervisão e a camada de validação que antes pertenciam às pessoas.

Harness não é um plugin. Harness é quando a máquina começa a crescer “uma camada de gestão”.

É isto que é realmente assustador.

01 Não é ferramenta, é “a camada que gere as ferramentas”

Muitas pessoas, ao verem harness, têm a primeira reacção: isto não é só mais uma framework de agent?

Essa compreensão é demasiado superficial.

A essência das ferramentas comuns é obedecer a instruções e executar. Tu clicas, ele faz. Tu não dizes nada, ele não se mexe.

Mas harness já não é esta lógica. O que ele faz, na verdade, é transformar a estrutura de divisão de trabalho que antes estava escondida dentro das equipas humanas em software:

Quem entende os requisitos, quem os divide em fases, quem executa, quem verifica, e quem, ao descobrir problemas, tem autoridade para devolver e mandar refazer.

Ou seja, a Anthropic não está a empilhar mais funcionalidades; está a escrever, no sistema, a própria questão de “como organizar o trabalho”.

Porque é que este passo é importante? Porque no passado o mais difícil de replicar nunca foi uma capacidade isolada, mas sim a capacidade de organização.

Há muitas pessoas que sabem escrever código.

Há poucas pessoas que conseguem organizar dezenas de pessoas, dezenas de passos e dezenas de rondas de retrabalho, e no fim entregar de forma estável.

E o harness está precisamente a tocar nessa camada mais cara.

Ferramentas aumentam a eficiência; a organização determina a produção.

Um modelo individual é apenas mão-de-obra. Harness está a tocar na estrutura de uma empresa.

Quando a IA não é só capaz de “fazer trabalho”, mas começa a saber dividir tarefas, fazer transições e assumir responsabilidades, deixa de ser apenas uma “actualização de ferramenta”.

02 Não é ficar mais inteligente; é ficar muito menos propenso a ficar pelo caminho

O ponto mais enganador do modelo é que, em tarefas curtas, parece sempre muito inteligente.

Pergunta-se uma questão e ele responde com lógica e clareza; pede-se que escreva um trecho de código e, muitas vezes, faz-o de forma bastante convincente. Então muita gente conclui erradamente: se as tarefas curtas conseguem, então as longas não são nada mais do que correr um pouco mais.

Não é nada disso.

O que torna as tarefas longas verdadeiramente difícil não é que um passo qualquer não saiba ser feito; é que, depois de dezenas de passos seguidos, ainda consiga manter-se fiel, sem perder o controlo, sem cair em auto-engano.

Fazer projectos com humanos é igual. O mais temido não é não saber; é começar a dar cabo lá no fim:

Os requisitos já não se lembram,

Os objectivos começam a desviar,

A lógica entre o início e o fim deixa de ser consistente,

E por fim, a melhor habilidade não é terminar as coisas, mas escrever um resumo que parece que foi feito.

O problema central referido no artigo da Anthropic é, em essência, este:

Em tarefas de longa duração, o modelo vai-se “desligando” gradualmente. Quanto maior o contexto, mais confuso o estado fica, e mais fácil é entrar cedo numa ilusão psicológica do tipo “está quase”.

O valor de Harness não está em deixá-lo mais “afinado”; está em fazê-lo ficar menos disperso, menos vazio e menos fácil de ser enganado.

Desmontar por fases, fazer transições, definir contractos, avaliação independente, e rollback em caso de falha — a estes elementos que parecem apenas detalhes de processo, na verdade resolvem o mesmo problema base:

A inteligência pode ser instável, mas a entrega não pode depender da sorte.

Portanto, se queres mesmo perceber harness, tens primeiro de perceber uma coisa:

O que vai ficar realmente valioso no futuro não é quem, ocasionalmente, consegue fazer um demo impressionante.

É quem consegue fazer com que o sistema avance continuamente, durante algumas horas, alguns dias, ou até mais tempo, sem deixar que o projecto fique pelo caminho.

Saber escrever, não é extraordinário.

Só é extraordinário se, no fim, não houver colapso.

Uma faísca momentânea não vale muito; o que vale é a entrega estável.

Alan diz que a lâmina mais fria neste artigo da Anthropic não é o planner, nem o generator, mas o evaluator.

Porquê?

Porque os grandes modelos têm um defeito muito semelhante ao dos humanos: acham que o que fizeram está “bem o suficiente”.

Desde que não haja restrições externas, é muito fácil darem uma auto-avaliação do tipo “no geral está bom”, “está essencialmente completo”, “as funcionalidades centrais já estão asseguradas”.

O problema é que, muitas vezes, esta avaliação não é mentira; é uma espécie de tolerância automática e sistémica para consigo mesmo.

Nas empresas humanas, porque é que tantos projectos acabam por falhar?

Porque quem faz o trabalho, muitas vezes, é quem melhor arranja razões para si.

A pessoa que faz diz que já está quase.

Quem valida não tem paciência para ver a fundo.

E assim algo “quase” passa de forma contínua, até chegar às mãos do utilizador e explodir.

O que a Anthropic faz com muita firmeza é separar directamente isto:

Quem executa é um papel.

Quem encontra falhas é outro papel.

O primeiro é responsável por avançar; o segundo é responsável por duvidar.

A lógica por trás disto é muito profunda:

Assim que o direito de produção e o direito de avaliação se separam, o sistema começa verdadeiramente a formar um circuito fechado.

E o mais assustador é que a Anthropic não está apenas a deixar o evaluator dizer umas frases do tipo “acho que aqui está mal”. Está, na medida do possível, a tornar a estrutura de “encontrar falhas” mais estruturada:

As funcionalidades têm de ser testadas, os pontos da página têm de ser verificados, as interfaces têm de ser consultadas, o estado da base de dados tem de ser observado, e a qualidade do design também é decomposta em dimensões que podem ser pontuadas.

O que é que isto significa?

Significa que muitos poderes que, no passado, eram misteriosamente atribuídos aos humanos para julgar, estão a ser decompostos, aos poucos, em processos, padrões e limiares.

O que é automatizado primeiro, muitas vezes, não é trabalho físico; é o trabalho de apontar problemas.

Logo que “isto serve mesmo ou não” seja transformado em processo, as “muralhas” baseadas em experiência de muita gente começam a ficar com fugas.

No passado, muitos cargos valiam a pena não porque sabiam produzir, mas porque tinham autoridade para dizer “isto conta como aprovado ou não”.

Agora, esse poder começa a afrouxar nas mãos das pessoas.

03 A lâmina mais dura é não o deixar elogiar-se a si mesmo

Alan diz que a lâmina mais fria neste artigo da Anthropic não é o planner, nem o generator, mas o evaluator.

Porquê?

Porque os grandes modelos têm um defeito muito semelhante ao dos humanos: acham que o que fizeram está “bem o suficiente”.

Desde que não haja restrições externas, é muito fácil darem uma auto-avaliação do tipo “no geral está bom”, “está essencialmente completo”, “as funcionalidades centrais já estão asseguradas”.

O problema é que, muitas vezes, esta avaliação não é mentira; é uma espécie de tolerância automática e sistémica para consigo mesmo.

Nas empresas humanas, porque é que tantos projectos acabam por falhar?

Porque quem faz o trabalho, muitas vezes, é quem melhor arranja razões para si.

A pessoa que faz diz que já está quase.

Quem valida não tem paciência para ver a fundo.

E assim algo “quase” passa de forma contínua, até chegar às mãos do utilizador e explodir.

O que a Anthropic faz com muita firmeza é separar directamente isto:

Quem executa é um papel.

Quem encontra falhas é outro papel.

O primeiro é responsável por avançar; o segundo é responsável por duvidar.

A lógica por trás disto é muito profunda:

Assim que o direito de produção e o direito de avaliação se separam, o sistema começa verdadeiramente a formar um circuito fechado.

E o mais assustador é que a Anthropic não está apenas a deixar o evaluator dizer umas frases do tipo “acho que aqui está mal”. Está, na medida do possível, a tornar a estrutura de “encontrar falhas” mais estruturada:

As funcionalidades têm de ser testadas, os pontos da página têm de ser verificados, as interfaces têm de ser consultadas, o estado da base de dados tem de ser observado, e a qualidade do design também é decomposta em dimensões que podem ser pontuadas.

O que é que isto significa?

Significa que muitos poderes que, no passado, eram misteriosamente atribuídos aos humanos para julgar, estão a ser decompostos, aos poucos, em processos, padrões e limiares.

O que é automatizado primeiro, muitas vezes, não é trabalho físico; é o trabalho de apontar problemas.

Logo que “isto serve mesmo ou não” seja transformado em processo, as “muralhas” baseadas em experiência de muita gente começam a ficar com fugas.

No passado, muitos cargos valiam a pena não porque sabiam produzir, mas porque tinham autoridade para dizer “isto conta como aprovado ou não”.

Agora, esse poder começa a afrouxar nas mãos das pessoas.

04 O que é comido primeiro não são programadores, é “quase serve”

Quando se vê um artigo assim, muita gente tem uma reacção automática e diz logo: os programadores é que vão acabar?

Alan diz que essa pergunta é demasiado superficial e demasiado preguiçosa.

A primeira vaga que harness “come” não é um nome de profissão específico.

Antes de mais, come uma forma de sobrevivência que existe há muito tempo e que é muito comum em quase todos os trabalhos do conhecimento:

Requisitos pouco claros, faz-se primeiro;

No meio faz-se ao lado, e depois completa-se;

O resultado é apenas mediano, mas dá para correr;

A documentação não está bem escrita, mas na equipa toda a gente entende;

Lança-se primeiro e, quando os problemas voltarem, corrige-se.

Em palavras simples, é um conjunto completo de modos de trabalhar baseados em espaços de ambiguidade e na elasticidade humana.

Muitos projectos ainda conseguem avançar não porque o processo seja realmente claro, mas porque, pelo meio, sempre há alguém a preencher as falhas com experiência, com coberturas e com julgamentos temporários.

O que o harness está a fazer é exactamente o contrário.

Está a comprimir os espaços de ambiguidade.

Está a comprimir os espaços de “desculpas”/“remendos”;

Está a comprimir os espaços de sobrevivência de “achei que…”, de “quase…”, de “deve dar”.

Define primeiro o que é done nesta ronda, antes de permitir começar;

Se não cumprir, manda de volta;

Se falhar a aprovação, continua;

Não comeces a sentir; apresenta provas.

Quando esta lógica avança, o mais perigoso nunca é a pessoa que melhor escreve código; é quem depende de sobreviver na zona cinzenta.

Harness não “come” programadores; primeiro come a ambiguidade.

Não é que toda a gente seja substituída, mas cada lugar que vive de forma vaga vai primeiro perder valor.

No passado, muitos cargos viviam de uma assimetria de informação; no futuro, muitos cargos vão morrer por causa da assimetria dos padrões.

05 Porque é que agora, de repente, está a dar tanto que falar

Muita gente vai perguntar: este tipo de coisas orientadas a workflows também alguém já fez antes; por que é que desta vez toda a gente começou a levar isto a sério?

Porque a base — o modelo — não era suficientemente forte antes.

Dizendo sem rodeios:

Muitos destes frameworks de antes pareciam muito bonitos, corriam com muita carga, mas não eram resistentes.

Tu montas uma pilha de processos, empilhas um monte de papéis, escreves um monte de regras; no fim, só embrulhas um modelo que nem é muito fiável, e transformas num sistema mais complexo, mas ainda assim pouco fiável.

Por isso, no passado, era normal muita gente perder a paciência com o conjunto de agent, workflow e scaffold.

Não foi porque a direcção estivesse errada; foi porque a base ainda não tinha chegado a esse nível.

Agora é diferente.

Quando o modelo passa um certo limiar, muitos processos que antes pareciam apenas decoração libertam, pela primeira vez, um valor real.

Porque quando a base do modelo é suficientemente forte, o processo deixa de servir para sustentar um “fracote”, e passa a amplificar um sistema que, por si, já consegue trabalhar continuamente.

É esta a razão pela qual harness, de repente, parece “um pouco real”.

Não é que a sua ideia só tenha aparecido hoje; é que o modelo finalmente ficou forte o suficiente para capturar os benefícios do processo.

A frase de Alan diz mesmo bem:

A capacidade do modelo é o motor, e Harness é a caixa de velocidades.

Sem um bom motor, mesmo a melhor caixa de velocidades é só um enfeite.

Mas quando o motor já é forte, é a caixa de velocidades que decide quem consegue ir para a auto-estrada e quem fica a dar gás parado.

Portanto, esta vaga não é apenas uma moda técnica; é a indústria a emitir um sinal mais profundo:

A competição futura não será só sobre quem tem modelos mais fortes; será sobre quem consegue primeiro integrar os modelos em sistemas de produção.

06 “Os humanos, por omissão, ficam no meio”

Por fim, Alan pousa o copo e diz a frase mais fria daquele dia:

“Antes eram os humanos a olhar para o software e a fazer trabalho; no futuro é o software a olhar para o software e a fazer trabalho.”

Porque é que esta frase “fere” tanto?

Porque ela revela que o que harness realmente reescreveu não é um cargo específico, mas sim um pressuposto mais de base, que quase ninguém questionava no passado:

No trabalho digital, por omissão, deve haver uma pessoa no meio.

Ele desmonta as tarefas,

Ele vigia o progresso,

Ele julga a qualidade,

Ele coordena o retrabalho,

Ele assegura a base final.

Essa “pessoa por omissão no meio” pode chamar-se programador, pode chamar-se PM, pode chamar-se TL, pode chamar-se responsável de design, pode chamar-se QA, ou pode chamar-se gestor de projecto.

O nome não importa.

O que importa é que, no passado, todo o sistema de produção digital tinha como premissa que não daria sem um “centro humano”.

O harness é o que realmente mexe nesse ponto central.

Não é que diga hoje “vamos pôr as pessoas a correr”; é a provar, pouco a pouco:

Que certas decomposições podem ser feitas pelo sistema;

Que certa supervisão pode ser feita pelo sistema;

Que certa validação pode ser feita pelo sistema;

Que certos rollbacks e reintentos também podem não exigir primeiro que as pessoas os descubram e depois tratem.

Quando esta prova aumenta cada vez mais, a posição das pessoas não desaparece de uma vez, mas começa a descer.

De centro por omissão, para intervenção em excepção;

De vigiar o ecrã o tempo todo, para tratar apenas os problemas das extremidades;

De dono do processo, para observador do processo.

É isto o que o harness “come” verdadeiramente.

Não são os programadores.

Não é o gestor de produto.

Não é a QA.

O que muda é o pressuposto mais profundo que está por trás destes papéis:

Por omissão, os humanos são o centro do processo.

E quando esse pressuposto começa a afrouxar, toda a história a seguir já não é a mesma.

Na era das ferramentas, ganha quem sabe usar melhor as ferramentas.

Na era do Harness, ganha quem aceita mais cedo:

Que ele já não está, por natureza, no centro do sistema.