Título original: Thin Harness, Fat Skills
Autor original: Garry Tan
Compilado por: Peggy, BlockBeats
Nota do editor: Quando 'modelos mais fortes' se tornam a resposta padrão da indústria, este artigo oferece um julgamento diferente: o que realmente cria uma diferença de produtividade de 10 vezes, 100 vezes ou até 1000 vezes não é o modelo em si, mas todo um sistema de design construído em torno do modelo.
O autor deste artigo, Garry Tan, é atualmente o presidente e CEO da Y Combinator, atuando há muito tempo em IA e no ecossistema de startups iniciais. Ele propôs a estrutura 'fat skills + thin harness', desmembrando a aplicação de IA em componentes-chave como habilidades, estrutura de execução, roteamento de contexto, divisão de tarefas e compressão de conhecimento.
Dentro desse sistema, o modelo não é mais tudo sobre capacidade, mas apenas uma unidade de execução no sistema; o que realmente decide a qualidade da saída é como você organiza o contexto, sedimenta processos e como você traça a linha entre 'julgamento' e 'cálculo'.
Mais importante, esse método não permanece em um nível conceitual, mas é validado em cenários reais: diante de tarefas de processamento e correspondência de dados de milhares de empreendedores, o sistema alcançou uma capacidade próxima à de analistas humanos por meio de um ciclo de 'ler - organizar - julgar - escrever de volta', e se auto-otimizou continuamente sem reescrever o código. Esse 'sistema que aprende' transformou a IA de uma ferramenta única em uma infraestrutura com efeito de juros compostos.
Assim, o aviso central dado pelo artigo também se torna claro: na era da IA, a diferença de eficiência não depende mais de você usar o modelo mais avançado, mas de você construir um sistema capaz de acumular habilidades continuamente e evoluir automaticamente.
Abaixo está o texto original:
Steve Yegge disse que pessoas que usam agentes de programação IA têm 'eficiência de 10 a 100 vezes maior do que aqueles que apenas escrevem código com Cursor e ferramentas de bate-papo, cerca de 1000 vezes maior do que engenheiros do Google em 2005.'
Nota: Steve Yegge é um influente engenheiro de software, blogueiro técnico e comentarista da cultura da engenharia no Vale do Silício, conhecido por seus artigos técnicos incisivos, longos e com um forte estilo pessoal. Ele trabalhou como engenheiro sênior na Amazon, Google e outras empresas; depois se juntou à Salesforce e a startups relacionadas à IA; também foi um dos primeiros promotores do projeto Dart.
Não é uma hipérbole. Eu vi com meus próprios olhos e vivi isso. Mas quando as pessoas ouvem essa diferença, muitas vezes atribuem-na à direção errada: modelos mais fortes, Claude mais inteligente, mais parâmetros.
Na verdade, as pessoas que melhoraram a eficiência em 2 vezes e as que melhoraram em 100 vezes estão usando o mesmo modelo. A diferença não está na 'inteligência', mas na 'arquitetura', e essa arquitetura é simples o suficiente para ser escrita em um cartão.
Harness (estrutura de execução) é o próprio produto.
Em 31 de março de 2026, a Anthropic acidentalmente publicou o código-fonte completo do Claude Code no npm — um total de 512 mil linhas. Eu li tudo. Isso validou o que venho dizendo na YC (Y Combinator): o verdadeiro segredo não está no modelo, mas na 'camada que envolve o modelo'.
Contexto do repositório de código em tempo real, cache de prompt, ferramentas projetadas para tarefas específicas, compressão de contexto redundante o máximo possível, memória de conversa estruturada, subagentes operando em paralelo — nada disso fará o modelo mais inteligente. Mas eles podem dar ao modelo o 'contexto correto' no 'momento certo', evitando que ele seja inundado por informações irrelevantes.
Essa camada 'envolvente' é chamada de harness (estrutura de execução). E a verdadeira pergunta que todos os construtores de IA devem fazer é: o que deve ser incluído no harness e o que deve ficar de fora?
Na verdade, essa questão tem uma resposta muito específica — eu a chamo de: estrutura fina (thin harness), habilidades grossas (fat skills).
Cinco definições
O gargalo nunca está na inteligência do modelo. O modelo já sabe como raciocinar, sintetizar informações e escrever código.
Eles falham porque não entendem seus dados — seu esquema, seus acordos, qual é a forma específica da sua questão. As cinco definições abaixo foram feitas exatamente para resolver esse problema.
1. Arquivo de habilidade (skill file)
Os arquivos de habilidade são documentos markdown reutilizáveis, projetados para ensinar o modelo 'como fazer algo'. Note que isso não é dizer ao modelo 'o que fazer' — isso é fornecido pelo usuário. Os arquivos de habilidade fornecem o processo.
O ponto chave que a maioria das pessoas ignora é que os arquivos de habilidade são como chamadas de método. Eles podem receber parâmetros. Você pode chamá-los com diferentes parâmetros. O mesmo processo, devido a diferentes parâmetros passados, pode exibir habilidades completamente diferentes.
Por exemplo, há uma habilidade chamada /investigate. Ela contém sete etapas: definir o escopo dos dados, construir uma linha do tempo, fazer diarização de cada documento, sintetizar, argumentar de ambos os lados, e citar fontes. Ela aceita três parâmetros: TARGET, QUESTION e DATASET.
Se você apontá-lo para um cientista de segurança e 2.100.000 e-mails de evidência, ele se tornará um analista de pesquisa médica, julgando se um denunciante foi silenciado.
Se você apontá-lo para uma empresa de fachada e documentos de declaração da Comissão Eleitoral Federal dos EUA (FEC), ele se tornará um investigador legal, rastreando doações políticas em ações colaborativas.
Ainda é a mesma habilidade. Ainda os mesmos sete passos. Ainda o mesmo arquivo markdown. A habilidade descreve um processo de julgamento, e o que realmente o traz para o mundo real são os parâmetros passados durante a chamada.
Isso não é engenharia de prompt, mas design de software: apenas aqui, usamos markdown como a linguagem de programação e o julgamento humano como o ambiente de execução. De fato, o markdown é até mais adequado para encapsular habilidades do que um código-fonte rígido, pois descreve processos, julgamentos e contextos, que são exatamente a linguagem que o modelo mais 'compreende'.
2. Harness (estrutura de execução)
Harness é a camada de programa que impulsiona o funcionamento do LLM. Ele faz apenas quatro coisas: faz o modelo operar em um ciclo, lê e escreve seus arquivos, gerencia o contexto e executa restrições de segurança.
É isso. Isso é 'thin (fino)'.
O padrão oposto é: harness gordo, habilidades magras.
Você certamente já viu isso: mais de 40 definições de ferramentas, só a descrição consome metade da janela de contexto; uma ferramenta God-tool tudo-em-um que leva de 2 a 5 segundos para passar por um MCP; ou então, encapsular cada endpoint da API REST como uma ferramenta separada. O resultado é que o uso de tokens triplica, a latência triplica, e a taxa de falhas também triplica.
A melhor prática real é usar ferramentas que são rápidas, estreitas e feitas para um propósito.
Por exemplo, um Playwright CLI, cada operação do navegador leva apenas 100 milissegundos; em vez de um Chrome MCP, que leva 15 segundos para fazer um screenshot → encontrar → clicar → esperar → ler. O primeiro é 75 vezes mais rápido.
O software agora não precisa mais ser 'excessivamente refinado'. O que você deve fazer é: construir apenas o que você realmente precisa, e nada mais.
3. Resolver (resolver)
resolver, é essencialmente uma tabela de roteamento de contexto. Quando o tipo de tarefa X aparece, prioriza carregar o documento Y. skills dizem ao modelo 'como fazer'; resolvers dizem ao modelo 'quando carregar o que'.
Por exemplo, um desenvolvedor alterou um prompt. Sem resolver, ele pode simplesmente lançar a versão após a alteração. Com um resolver, o modelo primeiro lê docs/EVALS.md. E este documento diz: primeiro execute a suíte de avaliação, compare as pontuações antes e depois; se a precisão cair mais de 2%, faça um rollback e investigue. Esse desenvolvedor nem sabia que a suíte de avaliação existia. Foi o resolver que carregou o contexto correto no momento certo.
Claude Code tem um resolver embutido. Cada habilidade tem um campo de descrição, e o modelo automaticamente combina a intenção do usuário com a descrição da habilidade. Você não precisa se lembrar se a habilidade /ship existe — a descrição em si é o resolver.
Para ser franco: meu CLAUDE.md anterior tinha 20 mil linhas. Todas as peculiaridades, todos os padrões, todas as experiências e lições que encontrei foram colocadas lá. Ridículo. A qualidade da atenção do modelo caiu visivelmente. Claude Code até me disse para eliminá-lo.
A última solução de reparo provavelmente terá apenas 200 linhas — mantendo apenas alguns ponteiros de documentos. O que realmente precisa de um documento, deixa que o resolver carregue o documento certo no momento crítico. Assim, 20 mil linhas de conhecimento ainda podem ser acessadas conforme necessário, mas não poluirão a janela de contexto.
4. Latente e determinístico (latent and deterministic)
Em seu sistema, cada passo pertence a uma dessas categorias ou à outra. E confundir essas duas é o erro mais comum no design de agentes.
·Espaço latente (latent space) é onde a inteligência reside. O modelo lê, entende, julga e toma decisões aqui. O que está sendo processado é: julgamento, síntese, reconhecimento de padrões.
·Determinístico (deterministic) é onde reside a confiabilidade. A mesma entrada sempre resulta na mesma saída. Consultas SQL, código compilado e operações aritméticas todos pertencem a este lado.
Um LLM pode ajudá-lo a organizar assentos para um jantar para 8 pessoas, considerando a personalidade e as relações sociais de cada um. Mas se você pedir para ele organizar assentos para 800 pessoas, ele criará um gráfico de assentos que 'parece razoável, mas na verdade está completamente errado'. Porque isso já não é um problema que o espaço latente deve lidar, mas um problema determinístico que foi forçado a entrar no espaço latente — um problema de otimização combinatória.
Os piores sistemas sempre colocam o trabalho no lugar errado, de ambos os lados dessa linha de demarcação. Os melhores sistemas, por outro lado, traçam limites de forma muito fria.
5. Diarization (documentação e organização de temas)
A diarização é o verdadeiro ponto-chave que permite que a IA gere valor no trabalho do conhecimento real.
Isso significa que o modelo lê todo o material relacionado a um tema e depois escreve uma imagem estruturada. Em uma página, ele condensa julgamentos de dezenas ou até centenas de documentos.
Isso não é algo que uma consulta SQL pode produzir. Isso também não é algo que uma linha de produção RAG pode produzir. O modelo realmente deve ler, manter informações contraditórias em mente, notar o que mudou, quando mudou, e então sintetizar essas informações em inteligência estruturada.
Essa é a diferença entre consultas de banco de dados e relatórios de analistas.
Esta arquitetura
Esses cinco conceitos podem ser combinados em uma arquitetura de três camadas muito simples.
·A camada superior é habilidades grossas (fat skills): processos escritos em markdown, que suportam julgamento, metodologia e conhecimento de domínio. 90% do valor está nesta camada.
·O meio é uma camada fina de CLI harness: cerca de 200 linhas de código, entrada JSON, saída de texto, somente leitura por padrão.
·A camada inferior é seu sistema aplicativo: QueryDB, ReadDoc, Search, Timeline — essas são as infraestruturas determinísticas.
O princípio central é direcionado: empurre a 'inteligência' o máximo possível para cima, para as habilidades; empurre a 'execução' o máximo possível para baixo, para ferramentas determinísticas; mantenha o harness leve e fino.
O resultado disso é que, sempre que a capacidade do modelo aumenta, todas as habilidades se tornam automaticamente mais fortes; enquanto o sistema determinístico subjacente permanece sempre estável e confiável.
Sistema que aprende
Aqui, vou usar um sistema real que estamos construindo na YC para mostrar como essas cinco definições trabalham juntas.
Em julho de 2026, Chase Center. A Startup School teve 6000 fundadores participando. Cada um tinha materiais de aplicação estruturados, respostas a questionários, transcrições de diálogos 1:1 com mentores e sinais públicos: postagens no X, registros de envios do GitHub, registros de uso do Claude Code (que mostram sua velocidade de desenvolvimento).
A abordagem tradicional é: 15 pessoas da equipe do projeto leem o pedido uma por uma, fazem um julgamento intuitivo e, em seguida, atualizam uma tabela.
Esse método ainda pode funcionar em uma escala de 200 pessoas, mas falha completamente em 6000 pessoas. Nenhum humano pode manter tantas imagens em mente ao mesmo tempo e perceber que os três melhores candidatos na infraestrutura de agente de IA são o fundador de ferramentas de desenvolvimento em Lagos, um empreendedor de conformidade em Cingapura e um desenvolvedor de ferramentas CLI em Brooklyn — e que eles descreveram a mesma dor de maneiras completamente diferentes em diferentes diálogos 1:1.
O modelo pode fazer isso. O método é o seguinte:
Enriquecimento (enrichment)
Há uma habilidade chamada /enrich-founder que puxa todas as fontes de dados, faz enriquecimento de informações, diarização, e destaca as diferenças entre 'o que o fundador disse' e 'o que realmente está fazendo'.
O sistema determinístico de base é responsável por: consultas SQL, dados do GitHub, testes de navegador de URL de demonstração, captura de sinais sociais, consultas CrustData, etc. Uma tarefa programada é executada uma vez por dia. Os perfis de 6000 fundadores permanecem sempre atualizados.
A saída da diarização pode capturar informações que buscas por palavras-chave não conseguem descobrir:
Fundador: Maria Santos Empresa: Contrail (contrail.dev) Auto-descrição: "O Datadog do agente de IA" O que realmente faz: 80% dos envios de código estão concentrados no módulo de faturamento → essencialmente, está fazendo uma ferramenta de FinOps disfarçada de observabilidade.
Essa diferença entre 'declaração vs comportamento real' precisa ler simultaneamente o histórico de commits do GitHub, materiais de aplicação e registros de diálogos, e integrar na mente. Nenhuma pesquisa de similaridade de embedding pode fazer isso, nem filtragem por palavras-chave. O modelo deve ler completamente e então fazer julgamentos. (Essa é a tarefa que deveria estar no espaço latente!)
Correspondência (Matching)
Este é o lugar onde 'habilidade = chamada de método' mostra seu poder.
A mesma habilidade de correspondência, chamada três vezes, pode gerar estratégias completamente diferentes:
/match-breakout: processa 1200 pessoas, agrupando por área, 30 pessoas por grupo (embedding + alocação determinística)
/match-lunch: processa 600 pessoas, 'coincidência acidental' intersetorial, 8 pessoas por mesa e não repetidas — o LLM gera primeiro o tema e depois um algoritmo determinístico organiza os assentos.
/match-live: processa participantes em tempo real no local, completando correspondência 1 a 1 em 200ms com base em embedding de vizinhos mais próximos, excluindo pessoas que já foram vistas.
E o modelo também pode fazer julgamentos que algoritmos tradicionais de agrupamento não conseguem realizar:
'Santos e Oram pertencem à infraestrutura de IA, mas não são concorrentes — Santos faz atribuição de custos, Oram faz orquestração. Devem estar no mesmo grupo.'
'Kim escreveu que estava solicitando ferramentas de desenvolvedor, mas a conversa 1:1 mostrou que ele estava fazendo automação de conformidade SOC2. Deve ser reclassificado para FinTech / RegTech.'
Essa reclassificação é algo que o embedding não consegue capturar. O modelo deve ler a imagem completa.
Ciclo de aprendizado (learning loop)
Após a atividade, uma habilidade /improve lerá os resultados da pesquisa NPS, fará diarização das feedbacks 'razoáveis' — não críticas, mas aquelas 'quase boas' — e extrairá padrões.
Então, ele fará novas regras e as escreverá de volta na habilidade de correspondência:
Quando os participantes dizem 'infraestrutura de IA', mas mais de 80% de seu código é módulo de faturamento:
→ Classificado como FinTech, e não IA Infra
Quando duas pessoas do mesmo grupo já se conhecem:
→ Reduzir o peso da correspondência
Priorizar a introdução de novas relações
Essas regras serão escritas de volta ao arquivo de habilidade. Automaticamente entrarão em vigor na próxima execução. As habilidades estão 'se reescrevendo'. Na atividade de julho, a pontuação 'razoável' representava 12%; na próxima atividade, caiu para 4%.
O arquivo de habilidade aprendeu o que 'razoável' significa, e o sistema se tornou melhor sem que ninguém reescrevesse o código.
Esse padrão pode ser transferido para qualquer domínio:
Buscar → Ler → diarize → Contar → Sintetizar
Então: pesquisa → investigação → diarize → reescrever habilidade
Se você quiser saber qual é o ciclo mais valioso de 2026, é este. Ele pode ser aplicado a praticamente todos os cenários de trabalho do conhecimento.
A habilidade é uma atualização permanente
Recentemente, publiquei uma instrução para o OpenClaw no X, e a reação foi maior do que o esperado:
Prompt: você não pode fazer trabalho único. Se eu pedir que você faça algo que será repetido no futuro, você deve: primeiro, processar manualmente de 3 a 10 amostras e me mostrar os resultados; se eu aprovar, escreva isso como um arquivo de habilidade; se deve ser executado automaticamente, adicione-o a tarefas agendadas. O critério de julgamento é: se eu tiver que perguntar uma segunda vez, isso significa que você falhou.
Este conteúdo recebeu milhares de curtidas e mais de duas mil coleções. Muitas pessoas pensaram que isso era uma técnica de engenharia de prompt.
Na verdade, não é, essa é a arquitetura que foi discutida anteriormente. Cada habilidade que você escreve é uma atualização permanente do sistema. Ela não se degrada, não esquece. Ela será executada automaticamente às três da manhã. E quando a próxima geração de modelos for lançada, todas as habilidades se tornarão instantaneamente mais fortes — a capacidade de julgamento da parte latente aumenta, enquanto a parte determinística permanece estável e confiável.
Essa é a origem da eficiência 100 vezes maior mencionada por Yegge.
Não são modelos mais inteligentes, mas sim: habilidades grossas, estruturas finas (Thin Harness, Fat Skills), e a disciplina de solidificar tudo como capacidade.
O sistema crescerá em juros compostos. Construa uma vez e opere a longo prazo.
[Link do texto original]