Harness magro, Skill gordo: a verdadeira fonte de produtividade AI 100 vezes maior

Título original: Harness Fino, Habilidades Robusta
Autor original: Garry Tan
Tradução: Peggy, BlockBeats

Autor original: BlockBeats

Fonte original:

Reprodução: Mars Finance

Nota do editor: Quando “modelos mais fortes” se tornam a resposta padrão na indústria, este artigo apresenta um julgamento diferente: o verdadeiro fator que amplia a produtividade por 10, 100 ou até 1000 vezes não é o modelo em si, mas toda uma arquitetura de sistema construída ao redor dele.

Este artigo, escrito por Garry Tan, atual presidente e CEO do Y Combinator, há muito tempo atua no ecossistema de IA e startups iniciais. Ele propõe a estrutura de “habilidades robustas + estrutura de execução leve”, decompondo a aplicação de IA em componentes-chave como habilidades, frameworks de operação, roteamento de contexto, divisão de tarefas e compressão de conhecimento.

Sob esse sistema, o modelo deixa de ser a totalidade da capacidade, tornando-se apenas uma unidade de execução; o que realmente determina a qualidade da saída é como você organiza o contexto, sedimenta processos e delimita as fronteiras entre “julgamento” e “cálculo”.

Mais importante ainda, esse método não fica na esfera conceitual, mas é validado em cenários reais: diante de tarefas de processamento e correspondência de dados de milhares de empreendedores, o sistema, por meio de um ciclo de “leitura—organização—julgamento—retorno”, alcança capacidades próximas às de analistas humanos, além de se auto-otimizar continuamente sem precisar reescrever código. Esse “sistema que aprende” transforma a IA de uma ferramenta pontual para uma infraestrutura com efeito de juros compostos.

Assim, a mensagem central do artigo fica clara: na era da IA, a diferença de eficiência não depende de usar o modelo mais avançado, mas de construir um sistema capaz de acumular capacidades continuamente e evoluir automaticamente.

A seguir, o texto original:

Steve Yegge disse que, ao usar agentes de programação de IA, “a eficiência é de 10 a 100 vezes maior do que a de engenheiros que escrevem código apenas com Cursor e ferramentas de chat, aproximadamente 1000 vezes maior do que os engenheiros do Google em 2005.”

Isso não é uma afirmação exagerada. Eu vi com meus próprios olhos, vivi isso na prática. Mas, ao ouvirem essa diferença, as pessoas tendem a atribuí-la ao caminho errado: modelos mais poderosos, Claude mais inteligente, mais parâmetros.

Na verdade, pessoas que aumentaram sua eficiência em 2 vezes e outras que aumentaram em 100 vezes usam o mesmo conjunto de modelos. A diferença não está na “inteligência”, mas na “arquitetura”, e essa arquitetura é simples o suficiente para caber em um cartão.

Harness (framework de execução) é o produto em si.

Em 31 de março de 2026, a Anthropic, de forma inesperada, lançou o código-fonte completo do Claude Code no npm — totalizando 512 mil linhas. Eu revisei tudo. Isso confirmou uma coisa que venho dizendo no YC (Y Combinator): o verdadeiro segredo não está no modelo, mas na “camada que envolve o modelo”.

Contexto de repositórios de código em tempo real, cache de prompts, ferramentas específicas para tarefas, compressão de redundância de contexto, memória estruturada de sessões, subagentes paralelos — tudo isso não torna o modelo mais inteligente. Mas garante que o modelo receba o “contexto correto” na “hora certa”, evitando que informações irrelevantes o sobrecarreguem.

Essa camada de “envolvimento” é chamada de harness (framework de execução). E a grande questão que os construtores de IA deveriam se fazer é: o que deve estar dentro do harness e o que deve ficar fora?

Na verdade, essa questão tem uma resposta bastante concreta — que chamo de: thin harness (estrutura leve) e fat skills (habilidades robustas).

Cinco definições

O gargalo nunca está na inteligência do modelo. Os modelos já sabem como raciocinar, integrar informações e escrever código.

Eles falham porque não compreendem seus dados — seu esquema, seus acordos, a forma específica do problema. E essas cinco definições são justamente para resolver esse problema.

1. Skill file (arquivo de habilidades)

O arquivo de habilidades é um documento markdown reutilizável que ensina ao modelo “como fazer uma coisa”. Atenção: não é dizer “o que fazer” — essa parte fica por conta do usuário. O arquivo de habilidades fornece o processo.

A maioria das pessoas ignora um ponto-chave: o arquivo de habilidades é como uma chamada de método. Pode receber parâmetros. Você pode chamá-lo com diferentes argumentos. A mesma sequência de passos, com parâmetros diferentes, exibe capacidades distintas.

Por exemplo, há uma habilidade chamada /investigate. Ela inclui sete etapas: definir o escopo dos dados, montar uma linha do tempo, diarizar cada documento, fazer síntese, argumentar de ambos os lados, citar fontes. Ela aceita três parâmetros: TARGET, QUESTION e DATASET.

Se você apontar essa habilidade para um cientista de segurança e 2,1 milhões de e-mails de evidências, ela se transforma em uma analista de pesquisa médica, para determinar se um denunciante foi silenciado.

Se apontar para uma empresa de fachada e documentos de declaração do FEC (Comissão Federal de Eleições dos EUA), ela vira uma investigadora forense, rastreando doações políticas coordenadas.

Ainda a mesma habilidade. Ainda os mesmos sete passos. Ainda o mesmo arquivo markdown. A habilidade descreve um fluxo de julgamento, mas o que realmente o traz para o mundo real são os parâmetros passados na chamada.

Isso não é engenharia de prompt, é design de software: só que aqui usamos markdown como linguagem de programação, e o julgamento humano como ambiente de execução. Na verdade, o markdown é até mais adequado do que código rígido para encapsular capacidades, pois descreve processos, julgamentos e contexto — exatamente a linguagem que o modelo “entende” melhor.

2. Harness (framework de execução)

Harness é a camada que conduz o funcionamento do LLM. Ele faz quatro coisas: faz o modelo rodar em loop, lê e escreve seus arquivos, gerencia o contexto, e aplica restrições de segurança.

Só isso. Essa é a essência do “thin” (leve).

O oposto seria: um harness pesado, habilidades frágeis.

Você já deve ter visto: dezenas de ferramentas definidas, ocupando metade da janela de contexto só na explicação; uma ferramenta “Deus” que faz tudo, levando de 2 a 5 segundos por rodada; ou endpoints de API REST transformados em ferramentas separadas. Resultado: o uso de tokens triplica, a latência triplica, a taxa de falhas triplica.

A abordagem ideal é usar ferramentas específicas, rápidas e com funções estreitas, criadas para o propósito.

Por exemplo, um CLI do Playwright, onde cada operação de navegador leva 100 ms; ao invés de um MCP do Chrome, que faz uma captura de tela, encontra, clica, espera, lê, tudo em 15 segundos. O primeiro é 75 vezes mais rápido.

Hoje, o software não precisa mais ser “embutido até ficar pesado”. O que você deve fazer é construir apenas o que realmente precisa, e nada mais.

3. Resolver (resolver)

Resolver é, na essência, uma tabela de roteamento de contexto. Quando aparece um tipo de tarefa X, prioriza-se carregar o documento Y. Skills ensinam “como fazer”; resolvers dizem “quando carregar o quê”.

Por exemplo, um desenvolvedor altera um prompt. Sem resolver, ele pode lançar a versão e seguir. Com resolver, o modelo primeiro lê docs/EVALS.md, que explica: executar o conjunto de avaliação, comparar as pontuações; se a precisão cair mais de 2%, fazer rollback e investigar. O desenvolvedor nem sabe que existe esse conjunto de avaliação. É o resolver que, no momento certo, carrega o contexto adequado.

Claude Code tem um resolver embutido. Cada skill tem um campo description, e o modelo automaticamente combina a intenção do usuário com a descrição da skill. Você nem precisa lembrar se o skill /ship existe — a descrição já funciona como resolver.

Para ser honesto, meu CLAUDE.md tinha 20 mil linhas. Todas as peculiaridades, padrões, lições aprendidas — tudo lá dentro. Era absurdo. A qualidade da atenção do modelo caiu visivelmente. Claude Code até me fez cortá-lo.

A solução final tem cerca de 200 linhas — apenas alguns ponteiros de documentos. Quando precisar de um documento, o resolver carrega na hora certa. Assim, os 200 mil linhas de conhecimento continuam acessíveis, sem poluir a janela de contexto.

4. Latent e deterministic (espaço latente e determinismo)

Em seu sistema, cada passo é ou uma coisa ou outra. Misturar esses conceitos é o erro mais comum no design de agentes.

· Espaço latente (latent space): é onde reside a inteligência. O modelo lê, entende, julga, decide aqui. Trata-se de julgamento, síntese, reconhecimento de padrões.

· Determinismo: é onde está a confiabilidade. Entrada igual, saída sempre igual. Consultas SQL, código compilado, operações aritméticas — tudo aqui.

Um LLM pode ajudar a organizar uma festa para 8 pessoas, considerando personalidades e relações sociais. Mas, para 800, ele pode criar uma lista de assentos “parecida com a real”, mas totalmente errada, porque essa não é uma tarefa de espaço latente, mas de otimização combinatória, que pertence ao espaço determinístico.

Os piores sistemas frequentemente confundem as fronteiras, colocando tarefas erradas em cada lado. Os melhores, delimitam com precisão.

5. Diarization (organização de documentos / perfil temático)

A diarization é a etapa que realmente traz valor ao conhecimento prático da IA.

Significa: o modelo lê todos os materiais relacionados a um tema, e gera uma representação estruturada. Resumindo em uma página, as avaliações de dezenas ou centenas de documentos.

Não é algo que uma consulta SQL consegue fazer. Nem uma pipeline RAG. O modelo precisa realmente ler, manter informações contraditórias na cabeça, perceber mudanças, e consolidar tudo em uma inteligência estruturada.

Essa é a diferença entre uma consulta a banco de dados e um briefing de analista.

Essa arquitetura

Esses cinco conceitos podem ser combinados em uma arquitetura simples de três camadas:

· Camada superior: habilidades robustas (fat skills): processos escritos em markdown, que carregam julgamento, metodologia e conhecimento de domínio. 90% do valor está aqui.
· Camada intermediária: um harness leve, com cerca de 200 linhas de código, que recebe JSON, produz texto, e é somente leitura por padrão.
· Camada inferior: seu sistema de aplicação: QueryDB, ReadDoc, Search, Timeline — infraestrutura determinística.

O princípio central é orientado: empurrar o “inteligente” para cima, para as skills; empurrar a “execução” para baixo, para ferramentas determinísticas; manter o harness leve.

O resultado é: toda vez que o modelo melhora, todas as habilidades também melhoram automaticamente; e o sistema determinístico de base permanece estável e confiável.

Sistema que aprende

A seguir, um exemplo de um sistema real que estamos construindo no YC, mostrando como esses cinco conceitos funcionam juntos.

Julho de 2026, Chase Center. Startup School com 6000 fundadores. Cada um com materiais estruturados, respostas a questionários, transcrições de reuniões 1:1 com mentores, e sinais públicos: postagens no X, commits no GitHub, registros de uso do Claude Code (que mostram a velocidade de desenvolvimento).

A abordagem tradicional: uma equipe de 15 pessoas lê cada inscrição, julga por intuição, e atualiza uma planilha.

Funciona até 200 pessoas, mas, com 6000, falha completamente. Nenhum humano consegue manter na cabeça tantas representações, percebendo que os três principais candidatos à infraestrutura de IA são: o fundador de ferramentas de desenvolvimento em Lagos, o empreendedor de conformidade em Cingapura, e o desenvolvedor de CLI em Brooklyn — e que, em conversas diferentes, descrevem o mesmo problema de formas totalmente distintas.

O modelo consegue fazer isso. Assim:

Enrichment (enriquecimento)

Há uma habilidade chamada /enrich-founder, que busca todas as fontes de dados, faz enriquecimento, diarization, e destaca as diferenças entre “o que o fundador diz” e “o que realmente faz”.

A infraestrutura determinística cuida de: consultas SQL, dados do GitHub, testes de URL de demonstração, captura de sinais sociais, consultas ao CrustData, etc. Uma tarefa agendada roda uma vez por dia. Os perfis de 6000 fundadores estão sempre atualizados.

A saída de diarization consegue captar informações que buscas por palavras-chave não conseguem:

Essa “diferença entre fala e ação” exige leitura de históricos do GitHub, materiais de inscrição e registros de diálogo, e sua integração na mente. Nenhuma busca por embedding ou filtro de palavras-chave consegue fazer isso. O modelo precisa ler tudo e julgar. (Essa é uma tarefa que pertence ao espaço latente!)

Matching (match)

É aqui que a “habilidade = método” mostra seu potencial.

O mesmo skill de matching, chamado três vezes, pode gerar estratégias completamente diferentes:

/match-breakout: agrupa 1200 pessoas por domínio, em clusters de 30 (embedding + alocação determinística)
/match-lunch: organiza 600 pessoas em encontros cruzados, 8 por mesa, sem repetições — primeiro gera tópicos, depois usa algoritmo determinístico para alocar assentos
/match-live: faz correspondência em tempo real, com base em embedding de vizinhos próximos, em 200 ms, excluindo quem já foi visto

E o modelo consegue fazer julgamentos que algoritmos tradicionais de clustering não conseguem:

" Santos e Oram são ambos infraestrutura de IA, mas não concorrentes — Santos faz atribuição de custos, Oram faz orquestração. Devem estar no mesmo grupo."
" Kim escreveu que está desenvolvendo ferramentas de desenvolvedor, mas a conversa 1:1 mostra que ele trabalha com automação de conformidade SOC2. Deve ser reclassificado para FinTech / RegTech."

Essa reclassificação não é captada por embedding. O modelo precisa ler o perfil completo.

Ciclo de aprendizado (learning loop)

Após a atividade, um /improve skill lê os resultados de NPS, faz diarization de feedbacks “ok” — não reclamações, mas “quase lá” — e extrai padrões.

Depois, propõe novas regras, que são inseridas na skill de matching:

Se alguém disser “infraestrutura de IA”, mas 80% do código é de módulos de cobrança: → classifica como FinTech, não IA Infra
Se duas pessoas do mesmo grupo já se conhecem: → reduz peso de correspondência, prioriza novas conexões

Essas regras são salvas no arquivo de skills. Na próxima execução, entram em vigor automaticamente. Skills se auto-reescrevem. Na atividade de julho, 12% de avaliações “ok”; na próxima, caem para 4%.

O sistema aprende o que significa “ok” e melhora sem que ninguém precise reescrever código.

Esse padrão pode ser aplicado a qualquer domínio:

Busca → leitura → diarization → contagem → síntese

Depois: pesquisa → investigação → diarization → reescrita de skills

Se você perguntar qual é o ciclo mais valioso em 2026, é exatamente esse. Pode ser aplicado a quase todas as tarefas de conhecimento.

Skills são atualizações permanentes

Recentemente, postei no X uma instrução para o OpenClaw, que teve uma resposta além do esperado:

A postagem recebeu milhares de curtidas e mais de duas mil salvamentos. Muitos pensaram que era uma técnica de engenharia de prompt.

Na verdade, não. É a arquitetura que descrevi acima. Cada skill que você escreve é uma atualização permanente do sistema. Ela não se degrada, não se esquece. Ela roda automaticamente às 3 da manhã. E, quando a próxima geração de modelos for lançada, todas as skills se tornam instantaneamente mais fortes — a capacidade de julgamento no espaço latente aumenta, enquanto o determinístico permanece estável e confiável.

Essa é a fonte da eficiência de 100 vezes que Yegge menciona.

Não é que o modelo seja mais inteligente, mas sim: habilidades robustas, estrutura leve (Thin Harness), e uma disciplina de solidificar tudo em capacidades.

O sistema cresce por juros compostos. Uma construção, que roda a longo prazo.