Harnesses são os novos Web Frameworks e isso é Bom!

No começo do ano, eu tava debatendo comigo mesmo se deveria migrar do Claude Code pro Codex. Fazia sentido: o Codex tinha prompts mais longos, suporte nativo a subagentes, uma arquitetura de ferramentas diferente. Passei uma tarde comparando, lendo docs, vendo benchmarks. No fim, fiquei onde tava. Mas a pulga atrás da orelha ficou.

Semana passada, trombei com um post do Paul Iusztin, autor da Decoding AI Magazine, uma newsletter que acompanho faz pouco tempo. Ele colocou em palavras exatamente o que eu tava sentindo:

"Harnesses are the new web frameworks. Everyone thinks they're choosing a competitive advantage. In 5 years, choosing Claude Code vs Codex will feel like choosing Django vs Rails. Important, but not strategic."

Li aquilo e fiz aquela cara de "alguém finalmente falou". Me inspirei no argumento dele e joguei minha leitura por cima. O que vem a seguir é minha versão comentada da ideia central, com exemplos do mundo real (incluindo um projeto meu que passou pelo teste dos dois harnesses).

Se você é dev e ainda acha que a escolha do harness (em bom português: a ferramenta que orquestra seu agente de IA) vai definir o sucesso do seu projeto, esse texto é pra você.

O 80% que todo harness compartilha

O ponto de partida do Paul é um exercício de humildade: ele dissecou Claude Code, Codex, OpenCode e Cursor componente por componente, tools, catálogo de agentes, subagentes, skills, memória, sandbox, permissões, e concluiu que 80% da arquitetura é idêntica.

Pensa em guitarras. Fender e Gibson brigam há mais de setenta anos, e guitarrista adora jurar fidelidade à sua marca. Mas desmonta uma e outra: corpo, braço, trastes, captadores, ponte. A anatomia é a mesma. O que separa um riff inesquecível de barulho genérico não é o logo no headstock. É quem está tocando e a música que escreveu. O harness é a guitarra. O som é seu.

Seja qual for o harness que você escolher, você vai ter:

Um registry de ferramentas (tools) que seguem o mesmo padrão: nome + schema + método execute
Agentes definidos em arquivos de configuração (YAML, Markdown, JSON)
Subagentes que rodam um loop separado com contexto reduzido
Skills — ou, em bom português, receitas de markdown que o modelo puxa sob demanda
Um sistema de permissões com allowlist/denylist
Uma camada de sandbox pra isolar execução

Isso não é coincidência. É commoditização acontecendo na nossa frente.

A pergunta certa mudou

O insight mais importante do artigo do Paul não é "os harnesses são iguais". É que a pergunta que a gente deveria estar fazendo mudou.

Antes: "Qual harness é melhor?"

Agora: "Pra cada componente, eu construo, configuro ou uso como está?"

E isso abre três caminhos:

Usar como está. O tool registry, o spawn de subagentes, o sandbox. Vem de graça. Não reinventa.

Configurar. Ajustar o catálogo de agentes, escrever skills, definir escopos de permissão. É aqui que a maioria de nós vai passar o tempo.

Construir. Criar ferramentas MCP específicas do seu domínio, sua camada de contexto, sua memória proprietária. É aqui que o valor mora.

O perigo? Errar a mão pros dois lados. Construir demais e gastar semanas reimplementando um tool loop que já vem pronto. Ou construir de menos e nunca criar a camada que é realmente sua, virando inquilino permanente do sistema de outro.

Mas isso é bom, não ruim

Vou ser sincero: quando li o post pela primeira vez, meu primeiro instinto foi defensivo. "Como assim, 'não é estratégico'? Passei meses configurando meu harness!"

Aí parei e pensei na época do Django vs Rails. Lá em 2008, a discussão mais quente da semana era qual framework escolher. Django tinha o admin pronto, Rails tinha a convenção sobre configuração, e você perdia horas em fóruns debatendo. Hoje? Ninguém pergunta qual framework um SaaS usa. Perguntam o que ele resolve.

O harness está no mesmo ponto. E isso é bom. Significa que a infraestrutura amadureceu o suficiente pra não ser mais uma decisão de risco. Você pode pegar qualquer um deles (Claude Code, Codex, Cursor, OpenCode) e entregar valor no primeiro dia. O que separa um projeto bem sucedido de um fracassado não é o harness. É o que você construiu em cima.

Onde o valor realmente está

Pega meu caso aqui: tenho um site de produtos afiliados. Montei um pipeline completo de extração de produtos afiliados da Amazon, Shopee e Mercado Livre, com categorização automática, geração de copy via DeepSeek, e dispatch direto pro WhatsApp. Funciona em crons, com rotação de categorias, scroll em página de busca, tudo via Playwright.

Sabe o que aconteceria se eu tivesse usado Codex em vez do Claude Code pra construir isso? Nada. Funcionaria igual. Porque o valor não está no harness que orquestra o pipeline, está no pipeline em si. Está na skill de extração que eu escrevi, na lógica de rotação de categorias, na integração com a API do Periskope. O harness é só a guitarra. O riff é meu.

O Paul vai além e detalha a arquitetura: o tool registry é a superfície commoditizada. O que você constrói como MCP server é o seu produto. O catálogo de agentes vem configurado de fábrica, e você raramente precisa criar um agente do zero, a menos que esteja construindo uma aplicação customizada (como eu fiz com minhas skills de deep research e escrita). As skills são o melhor retorno sobre esforço: escrever uma skill markdown é a forma mais barata de ensinar seu agente a fazer algo específico do seu domínio. Pra ter ideia, eu tenho uma skill de deep research que instrui o agente a estruturar pesquisas no meu estilo, e já sabendo como eu pesquisaria ele monta uma lista de links com referências e sugestões para que eu estude e escreva sobre um assunto. E pra você ver que não tem mágica nenhuma, o começo dela é literalmente isso:

---
name: deep-research
description: Multi-source deep research using firecrawl and exa MCPs.
  Searches the web, synthesizes findings, and delivers cited reports.
---

# Deep Research

## When to Activate
- User asks to research any topic in depth
- Competitive analysis, technology evaluation, or market sizing

## Workflow
### Step 1: Understand the Goal
Ask 1-2 quick clarifying questions

### Step 2: Plan the Research
Break the topic into 3-5 research sub-questions

Cada skill é um arquivo de texto. Menos de 100 linhas. Funciona em qualquer harness.

Quando dar um passo atrás

Essa tese não vale pra todo mundo. Se você está numa big tech com requisitos bizarros de isolamento — tipo rodar agentes não-confiáveis em processos separados — aí a escolha do harness faz diferença. Mas isso é a exceção, não a regra.

Pra 90% dos times, a melhor estratégia é: escolhe um harness qualquer, aprende o básico em um fim de semana, e gasta o resto do tempo construindo o que realmente importa: suas skills, seu contexto, seu domínio.

Fechando

O Paul Iusztin publicou o artigo completo "Build, Configure, or Use As-Is: The Agentic Harness" na Decoding AI Magazine (que, aliás, tem mais de 41 mil assinantes e é leitura obrigatória se você trabalha com engenharia de IA). Recomendo ler o original: ele dissecou cada componente com uma profundidade que não caberia aqui. O que fiz foi traduzir a ideia central e jogar minha experiência em cima.

E você? Já passou pela novela de escolher entre Claude Code e Codex? Descobriu que no fim das contas tanto faz? Me conta nos comentários qual foi sua descoberta mais inesperada sobre o harness que você usa.