Harness Engineering: A Ideia Certa Sobre a Fundação Errada

Há um novo termo a ganhar força no espaço da engenharia de AI: harness engineering.

A ideia é atraente. À medida que os agentes de AI assumem mais execução — escrever código, gerir fluxos de trabalho, tomar decisões operacionais — o papel humano desloca-se de escrever linhas de código individuais para algo, defensavelmente, mais importante: definir os ambientes, os constrangimentos e os ciclos de feedback que permitem aos agentes operar de forma eficaz.

Por outras palavras, os humanos tornam-se os arquitetos do espaço. Os agentes tornam-se os executores dentro dele.

Concordo com esta direção. Faz sentido. Os agentes, como os humanos, precisam de orientação e de fronteiras. O conceito de engenheirar essas fronteiras como uma disciplina formal está atrasado.

Mas — e sabia que vinha aí um «mas» — esta conversa parece ter dois pontos cegos que merecem mais atenção do que estão a receber.

Ponto Cego #1: A Proliferação de Agentes Aí Vem — E Já Vimos Este Filme

Lembra-se de quando os microserviços eram a resposta para tudo?

Cada conferência falava de partir monólitos em pequenos serviços independentes. Cada equipa apressava-se a fazer deploy de dezenas, depois centenas, de microserviços. Era moderno. Era escalável. Era o futuro.

E depois a realidade bateu à porta. As organizações viram-se a afogar-se num pesadelo de orquestração que poucas tinham planeado. Serviços a chamar serviços a chamar serviços, com visibilidade limitada sobre o que dependia de quê. As ferramentas para gerir a complexidade chegaram depois de a complexidade já ser ingerível.

A proliferação de agentes vai seguir o mesmo padrão — mas com uma diferença crítica.

Os microserviços executam lógica determinística. Quando o serviço A chama o serviço B, consegue-se prever o resultado. Os agentes tomam decisões autónomas. Quando o agente A interage com o agente B, o espaço de resultados é exponencialmente maior. O raio de rebentamento de «demasiados, mal governados» não é uma degradação lenta — é uma cascata imprevisível.

Os harness engineers que esta nova disciplina promete? Arriscam ficar sobrecarregados antes de o primeiro ciclo de feedback sequer se completar. Não porque o conceito esteja errado, mas porque as organizações tendem a fazer o que sempre fizeram: fazer deploy primeiro, governar depois.

Não precisamos de mais agentes. Precisamos de governação de agentes antes de precisarmos de mais agentes.

Ponto Cego #2: Não Se Consegue Controlar o Que Assenta Sobre uma Fundação Partida

Eis a pergunta que a conversa sobre harness engineering tende a contornar: sobre o que é que o agente realmente opera?

O conceito original fala em «tornar a própria base de código compreensível para o agente». Isto soa razoável num slide de conferência. Na prática, pressupõe algo que raramente existe em ambientes empresariais — uma base de código que pode ser prontamente compreendida.

Passei mais de três décadas a trabalhar dentro de infraestrutura crítica — sistemas de pagamento, banca, telecomunicações. Posso dizer-lhe qual é o aspeto real da maioria das bases de código empresariais:

• Décadas de dívida técnica acumulada
• Documentação que estava desatualizada no dia em que foi escrita — se é que foi escrita
• Workarounds empilhados sobre workarounds, onde a razão original do workaround foi há muito esquecida
• Decisões de arquitetura movidas por relações com fornecedores, não por requisitos
• Conhecimento que existe apenas nas cabeças de pessoas perto da reforma

Fazer deploy de agentes em cima disto é como pôr um motor de Fórmula 1 num carro sem suspensão. O motor é magnífico. O carro desfaz-se à primeira curva.

O agente não corrige a sua infraestrutura partida. O agente amplifica-a. Cada ineficiência, cada dependência não documentada, cada compromisso arquitetural de 2004 que «corrigimos depois» — o agente vai encontrá-lo, interagir com ele, e propagá-lo à velocidade da máquina.

Antes de engenheirarmos o harness, precisamos de engenheirar aquilo sobre que o harness assenta.

A Conversa Que Continua a Ser Adiada

Há uma razão para esta parte da discussão tender a ser adiada. Corrigir infraestrutura é caro, lento, politicamente difícil, e profundamente sem glamour. É difícil construir um argumento de negócio convincente em torno de «passámos 18 meses a limpar dívida técnica para que os nossos agentes tivessem uma fundação sólida». É muito mais fácil apresentar «fizemos deploy de 47 agentes de AI pelas nossas operações».

Mas eis o que três décadas de realidade empresarial me mostraram: as organizações que saltam o trabalho de fundação vão provavelmente passar mais tempo a depurar os seus agentes do que os agentes passam a fazer trabalho útil.

A harness engineering enquanto conceito é sólida. A direção é certa. Mas um harness só é tão bom quanto aquilo a que está preso.

Um agente com barreiras de proteção perfeitas, a operar num ambiente bem definido, com ciclos de feedback claros — em cima de infraestrutura que nunca foi desenhada para interação com agentes — continua a ser um agente à espera de amplificar a coisa errada no pior momento.

Então O Que Podemos Fazer Quanto a Isso?

É fácil apontar problemas. O que é mais difícil — e mais útil — é pensar em passos práticos. Estas não são prescrições. Cada organização é diferente. Mas são perguntas e abordagens que podem ajudar a afiar o pensamento antes de a pressão do deploy vencer.

Comece por um diagnóstico honesto — não uma auditoria de caixas assinaladas.

Antes de fazer deploy de um único agente, percorra a infraestrutura que ele vai tocar. Não num diagrama — na realidade. Onde está a documentação? Onde estão as dependências não documentadas? Onde é que o conhecimento vive apenas na cabeça de alguém? Isto não é sobre encontrar culpados. É sobre compreender o que um agente encontraria de facto no primeiro dia. A maioria das organizações fica surpreendida com o que este exercício revela.

Separe «pronto-para-agentes» de «possível-com-agentes».

Que um agente possa ser implementado num sistema não significa que o sistema esteja pronto para ele. Um exercício útil: para cada processo candidato, pergunte «se este agente tomar uma decisão errada às 3 da manhã, com que rapidez a conseguimos detetar, compreender e reverter?». Se a resposta envolve acordar três pessoas que detêm, cada uma, uma peça diferente do puzzle, o sistema não está pronto-para-agentes — está possível-com-agentes. Há uma diferença significativa.

Trate a remediação como investimento, não como custo.

Limpar dívida técnica, documentar conhecimento tribal, resolver workarounds arquiteturais — este trabalho é muitas vezes classificado como custo. É, na verdade, o investimento de maior ROI que uma organização pode fazer antes de qualquer deploy de AI. Um agente a operar sobre uma fundação limpa e bem documentada entregará valor composto. O mesmo agente sobre uma fundação frágil entregará problemas compostos. A matemática é simples, mesmo que a conversa de orçamento não o seja.

Governe a população antes que ela o governe a si.

A lição dos microserviços está disponível para quem estiver disposto a aprender com ela: defina fronteiras de quantidade, âmbito e autoridade antes do deploy, não depois de a orquestração se tornar ingerível. Para os agentes, isto significa responder cedo a perguntas incómodas: Quantos agentes são suficientes? Quem autoriza o deploy de um novo agente? Qual é o critério de retirada de um agente que já não é preciso? Estas perguntas parecem burocráticas até a alternativa se tornar real.

Construa primeiro os ciclos de feedback para os humanos, depois para os agentes.

A harness engineering enfatiza os ciclos de feedback para os agentes — e bem. Mas considere isto: se a sua organização ainda não tem ciclos de feedback eficazes para a tomada de decisão humana (caminhos de escalada claros, revisões pós-incidente que de facto mudam o comportamento, métricas que medem resultados em vez de atividade), acrescentar ciclos de feedback de agentes por cima não resolverá a lacuna estrutural. Acrescentará uma camada de dados que os ciclos humanos existentes não estão equipados para processar.

A Sequência Importa

Se há uma conclusão a tirar de tudo isto, é que a ordem importa mais do que a ambição.

Diagnostique antes de fazer deploy. Remedeie antes de automatizar. Governe antes de escalar. Depois — e só depois — engenheire o harness.

Esta sequência é mais lenta. É menos impressionante numa revisão trimestral. Não gera o tipo de anúncios que são tendência no LinkedIn.

Mas funciona. E em ambientes empresariais onde a falha não é uma oportunidade de aprendizagem mas um impacto direto em milhões de transações, clientes ou operações — «funciona» é a única métrica que importa.

O Essencial

A harness engineering não está errada. Está incompleta.

A conversa sobre como os humanos devem estruturar o espaço para os agentes de AI é necessária e está atrasada. Mas tende a saltar a pergunta mais difícil, mais cara e mais importante: estará o próprio espaço pronto para agentes?

Na maioria das empresas, a resposta honesta é «ainda não». E isso não é uma falha — é uma oportunidade. As organizações que dedicam tempo a preparar a fundação serão aquelas onde a harness engineering de facto cumpre a sua promessa.

A ideia certa, sobre a fundação certa, no momento certo. É essa a combinação que vale a pena perseguir.