Software depois da IA: o início da era do harness

• O fim da era do software é o início da era do harness, e o SaaS que operava com fluxos de trabalho fixos e bancos de dados gerenciados está sendo substituído por IA com inteligência
• A IA é poderosa, mas, como um cavalo selvagem, ainda não foi domada; para aproveitar sua força, é necessário um processo de controle sistemático (domestication)
• O harness de agentes de IA é definido por 7 componentes centrais ao redor de um LLM no centro, e cada elemento determina a confiabilidade e o desempenho em nível de produção
• Em uma era em que todas as empresas têm acesso aos mesmos modelos, o vencedor não é o modelo em si, mas quem projeta e opera melhor o harness (best rider)
• Milhares de mercados separados que os grandes labs não priorizam continuam sendo oportunidade para startups

---

O significado da era do harness

• A IA está substituindo por inteligência (intelligence) o SaaS baseado em fluxos de trabalho fixos e os bancos de dados gerenciados, redefinindo o paradigma de software
• A IA é comparada a um mustang: poderosa, porém bruta, e não pode ser usada como está; o processo de domá-la é justamente o harness
• A essência dessa domesticação é uma arquitetura com o LLM no centro e 7 componentes dispostos radialmente ao seu redor

Os 7 componentes do harness de agentes de IA

• 1. Context & Memory (contexto e memória)

  • Modelos de uso geral exigem retrieval sob medida para cada caso (bespoke retrieval); um sistema de busca de contexto para radiologistas não pode ser igual ao de assistentes jurídicos
  • Memória de curto prazo ("o que o agente estava fazendo há 45 segundos"), busca de imagens em larga escala (radiologia/geração de imagem), busca por palavras-chave em bilhões de documentos etc. exigem sistemas diferentes conforme o caso
  • Ao lado da busca fica o banco de dados de contexto, que funciona como um "livro de receitas" de como o negócio realmente opera
    • Os procedimentos operacionais padrão (SOP) que as pessoas carregam na cabeça ao chegar ao trabalho são justamente essa receita
    • A captura inicial e a evolução conforme pessoas e processos mudam são a essência do banco de dados de contexto

• 2. Tools & Action (ferramentas e ação)

  • Ferramentas são o meio pelo qual o agente afeta o mundo externo; se a receita do banco de contexto define o que fazer, as ferramentas são os materiais e instrumentos que executam isso de fato
  • O harness moderno expõe ferramentas por meio de um registry, valida os argumentos enviados pelo modelo, despacha chamadas, faz operações sensíveis passarem por gates de aprovação e processa os resultados de volta no loop do agente
  • MCP está emergindo como o tecido conjuntivo (connective tissue) para conectar ferramentas
  • A qualidade do harness é determinada pela quantidade de ferramentas que ele consegue expor com segurança e pela capacidade de tratar falhas de forma limpa

• 3. Orchestration & Loop (orquestração e loop)

  • O loop do agente tem a estrutura think → act → observe → repeat
  • Planejamento, decomposição de tarefas, subagentes, retries e condições de interrupção definem como o trabalho é executado
  • O sistema deve melhorar com o uso, e o padrão de closed loop que aprende com cada execução é um fator de diferenciação entre fornecedores

• 4. State & Persistence (estado e persistência)

  • Em grandes empresas, onde muitas pessoas usam o sistema ao mesmo tempo, resiliência (resilient) é essencial
  • Se o harness falhar na etapa 7 de um processo de 10 etapas, ele deve retomar da etapa 8, e não recomeçar do zero
  • Sistema de arquivos, checkpoints, threads de sessão e armazenamento de artefatos são mecanismos para evitar perda de trabalho

• 5. Sandbox & Compute (sandbox e computação)

  • Cada agente precisa de um espaço de trabalho isolado (sandbox)
  • Workspaces Unix isolados, egress de rede controlado e credenciais armazenadas fora do modelo garantem segurança, confidencialidade e velocidade em escala

• 6. Observability & Governance (observabilidade e governança)

  • "O que não pode ser visto não pode ser confiado" — rastrear todas as etapas, registrar todas as chamadas de ferramentas, executar evals como testes de regressão e incluir human-in-the-loop nas decisões de maior risco é o que transforma uma demo em sistema de produção
  • Guardrails impõem políticas, e Evals detectam regressões antes dos clientes

• 7. Cost & Workflow Optimization (custo e otimização de workflow)

  • O sétimo componente é o julgamento arquitetural (architectural judgment)
  • É preciso decidir o que deve ser tratado de forma determinística vs. não determinística, escolher o modelo adequado para cada etapa (de ponta, médio, pequeno, fine-tuned) e definir se o conhecimento deve ficar em skills ou em memória

Nova dinâmica competitiva

• O resultado é uma nova dinâmica competitiva do software, que não se aplica da mesma forma a todas as categorias
• Mercados priorizados pelos grandes labs (principais laboratórios de IA) se beneficiam de execução rápida e controle direto sobre o modelo
• Mas, fora disso, milhares de mercados distintos permanecem abertos para startups
• Em uma era em que todas as empresas podem usar os mesmos modelos, "os melhores cavaleiros (best riders)" vencem — ou seja, a capacidade de projetar e operar o harness é a principal vantagem competitiva

[junghan0611]

Como o pi é bem leve, eu o uso bastante como ferramenta de agente. Além disso, como também queria conectar o Claude Code e o Gemini, criei o pi-shell-acp e tenho usado bem. Faço e uso várias skills, e quanto mais testo, mais percebo que customizar ao meu jeito é o ideal. Quando vou usar diretamente Claude Code, Codex etc., deixo no modo YOLO e desligo praticamente todas as ferramentas embutidas até o nível do pi. Função nova, assim que aparece, eu já desligo na hora.

[runai]

Eu removi todas as configurações de harness que eu tinha.
À medida que o modelo evolui, o harness passa a atuar como um fator que limita o desempenho do modelo.
Configurações de harness mal feitas acabam produzindo resultados ainda piores.
As configurações de harness que já existiam até a 4.7 não fazem mais sentido na 4.8
e no GPT 5.5 só atrapalham.

[hanje3765]

Os componentes de harness mencionados no texto não são coisas que seriam resolvidas simplesmente porque a inteligência dos LLMs aumenta.

Se você estiver falando de harnesses da época em que a definição de harness ainda era pouco clara, acho que isso pode até fazer sentido, mas, se for o harness descrito no texto, parece ser uma área que precisará continuar sendo gerenciada no futuro.

[runai]

Em vez de ser uma questão de inteligência, os modelos também estão desenvolvendo, separadamente da inteligência, capacidades de uso como orquestração e ferramentas. A área de orquestração era imediatamente uma das partes centrais do Harness, mas agora até isso já é suportado. Então, neste momento, se existem uma orquestração improvisada e uma orquestração oficial, qual faz mais sentido usar?

[kaydash]

Concordo. Precisamos desenvolver uma resposta juntos.

[emptybynature]

Há um post oficial sobre harnessing publicado no site da OpenAI. O conteúdo compartilha experiências e dicas sobre como o harnessing foi usado internamente na OpenAI. Ou seja, até a própria OpenAI usa harnessing em seus projetos internos. O harnessing é claramente necessário e impacta diretamente a qualidade final da implementação. Acima de tudo, ele pode reduzir pela metade a quantidade de tokens necessária para implementar um resultado com a mesma qualidade. Dá para obter desempenho e custo ao mesmo tempo, então não há motivo para não usar.

[runai]

No Opus 4.8, foi adicionado o ultracode effort, e isso resolve melhor do que antes o trabalho que o modo Harness manual do desenvolvedor fazia. Portanto, neste momento, acho melhor remover a parte de orquestração do modo Harness que vocês estavam usando.

[gulbi135]

Concordo. Eu também removi a orquestração artesanal para a 4.7 e a imposição de um planejamento prolixo, porque no 4.8 isso acabou virando um atrapalho.
Mas, em um codebase com centenas de milhares de linhas mantido por anos, o valor real do harness não está na orquestração, e sim na camada que o ultracode não consegue substituir (grafo de conhecimento, convenções de domínio, invariantes de validação). Por isso, mantive essa camada de contexto e paralelizei com workflow apenas os trechos realmente independentes.
Por outro lado, se for um projeto novo, acho que ultracode faz mais sentido mesmo sem harness. No fim, parece menos uma questão de "apagar vs manter" e mais algo que depende da idade do codebase e do nível de acoplamento.

[runai]

Sim. Você está certo. A parte sem a orquestração ainda tem valor.