Cinto Fino, Habilidade Gorda: A Verdadeira Fonte de 100x de Produtividade em IA

Título do Artigo Original: Cinto Fino, Habilidades Gordas
Autor do Artigo Original: Garry Tan
Tradução: Peggy, BlockBeats

Nota do Editor: À medida que os "modelos mais fortes" se tornam a resposta padrão na indústria, este artigo oferece uma perspectiva diferente: o que realmente alarga as lacunas de produtividade em 10x, 100x ou até 1000x não é o modelo em si, mas um design de sistema completo construído em torno do modelo.

O autor deste artigo, Garry Tan, atual Presidente e CEO da Y Combinator, tem estado envolvido há muito tempo em IA e ecossistemas de startups em fase inicial. Ele apresenta o quadro "habilidades gordas + cinto fino", decompondo as aplicações de IA em componentes-chave como habilidades, estrutura de execução, roteamento de contexto, divisão de tarefas e compressão de conhecimento.

Neste sistema, o modelo já não é toda a capacidade, mas apenas uma unidade de execução dentro do sistema. O que realmente determina a qualidade da saída é como organiza o contexto, solidifica os processos e delineia a fronteira entre "inferência" e "cálculo."

Mais importante ainda, esta abordagem não é meramente conceptual, mas foi validada em cenários reais: confrontado com tarefas de processamento e correspondência de dados de milhares de empreendedores, o sistema alcança capacidades próximas a analistas humanos através de um ciclo de "ler-resumir-inferir-escrever de volta", auto-otimizando continuamente sem a necessidade de reescritas de código. Este "sistema de aprendizagem" transforma a IA de uma ferramenta pontual em uma infraestrutura com um efeito de acumulação.

Assim, a mensagem central fornecida no artigo torna-se clara: na era da IA, as lacunas de eficiência não são mais determinadas por se utilizar o modelo mais avançado, mas por se ter construído um sistema que pode acumular continuamente capacidades e evoluir automaticamente.

O seguinte é o texto original:

Steve Yegge disse que aqueles que utilizam agentes de programação em IA são "10 a 100 vezes mais eficientes do que engenheiros que apenas programam com um cursor e ferramentas de chat, aproximadamente 1000 vezes mais eficientes do que um engenheiro do Google de 2005."

Nota: Steve Yegge é um engenheiro de software altamente influente, blogger técnico e comentador da cultura de engenharia no Vale do Silício, conhecido pelos seus artigos técnicos longos, incisivos e fortemente opinativos. Ele atuou como engenheiro sénior em empresas como a Amazon e o Google, juntando-se depois à Salesforce, passando por startups na área da IA, e também sendo um dos primeiros defensores do projeto Dart.

Isto não é uma exageração. Eu vi isso com os meus próprios olhos e experimentei-o em primeira mão. No entanto, quando as pessoas ouvem sobre tal diferença, muitas vezes a atribuem a fatores errados: um modelo mais forte, um Claude mais inteligente, mais parâmetros.

Na realidade, a pessoa que é duas vezes mais eficiente e aquela que é cem vezes mais eficiente estão a usar o mesmo modelo. A diferença não está na "inteligência" mas na "arquitetura," e esta arquitetura é tão simples que pode caber num cartão de notas.

O Harness (Framework de Execução) é o Produto em Si.

No dia 31 de março de 2026, numa reviravolta inesperada, a Anthropic lançou acidentalmente o código fonte completo do Claude Code para npm—totalizando 512.000 linhas. Eu li tudo. Isto validou algo que sempre falei na YC (Y Combinator): o verdadeiro segredo não está no modelo, mas na "camada que envolve o modelo."

Contexto da base de código em tempo real, cache de prompts, ferramentas desenhadas para tarefas específicas, compressão máxima de contexto redundante, memória de sessão estruturada, subagentes a correr em paralelo—nenhum destes torna o modelo mais inteligente. Mas podem fornecer ao modelo o "contexto certo" no "momento certo," enquanto evitam ser sobrecarregados por informações irrelevantes.

Esta camada de envolvimento é chamada de harness (framework de execução). E a verdadeira questão que todos os construtores de IA devem fazer é: O que deve entrar no harness, e o que deve ficar de fora?

Curiosamente, esta questão tem uma resposta muito específica—um harness fino, habilidades robustas.

Cinco Definições

O estrangulamento nunca esteve na inteligência do modelo. O modelo já sabe como raciocinar, sintetizar informações e escrever código.

Eles falham porque não compreendem os seus dados—o seu esquema, os seus acordos, que forma assume o seu problema. E as seguintes cinco definições são precisamente concebidas para abordar esta questão.

1. Ficheiro de Competências

Um ficheiro de competências é um documento markdown reutilizável que ensina ao modelo "como fazer algo." Note que não lhe diz "o que fazer"—essa parte é fornecida pelo utilizador. O ficheiro de competências fornece o processo.

O ponto chave que a maioria das pessoas ignora é este: um ficheiro de competências é, na verdade, como uma chamada de método. Pode aceitar parâmetros. Pode chamá-lo com diferentes parâmetros. O mesmo processo, quando chamado com diferentes entradas, pode demonstrar capacidades vastamente diferentes.

Por exemplo, existe uma competência chamada /investigar. Consiste em sete etapas: Definir o âmbito dos dados, Construir a linha do tempo, Diarizar cada documento, Sintetizar, Argumentar de ambos os lados, Citar fontes. Aceita três parâmetros: ALVO, QUESTÃO e CONJUNTO DE DADOS.

Se o direcionar para um cientista de segurança e 2,1 milhões de e-mails forenses, ele transformará-se num analista de investigação médica para determinar se um denunciador foi silenciado.

Se o direcionar para uma empresa de fachada e os registos de divulgação da Comissão Eleitoral Federal (FEC), ele transformará-se num investigador forense de litígios para rastrear doações políticas coordenadas.

Mesma competência. Mesmos sete passos. Mesmo ficheiro markdown. A habilidade descreve um processo de tomada de decisão, e o que realmente o traz à vida são os parâmetros de entrada em tempo de execução.

Isto não é engenharia de prompt, mas design de software: aqui, o markdown é a linguagem de programação, e o julgamento humano é o ambiente de execução. Na verdade, o markdown é ainda mais adequado para encapsulamento do que código fonte rígido, porque descreve o processo, o julgamento e o contexto, que são a linguagem que o modelo compreende melhor.

2. Harness (Framework de Execução)

Harness é a camada de software que impulsiona a operação do LLM. Faz apenas quatro coisas: executa o modelo em loop, lê e escreve os seus ficheiros, gere o contexto e impõe restrições de segurança.

É isso. Isso é "fino."

O padrão oposto é: harness gordo, habilidades finas.

Provavelmente já viu isto: mais de 40 definições de ferramentas, onde a documentação sozinha ocupa metade do ecrã; uma ferramenta Deus todo-poderosa que leva de 2 a 5 segundos para ir e voltar ao Gerador de Dados Controláveis; ou envolver cada ponto final de uma API REST numa ferramenta separada. O resultado é o triplo do uso de tokens, triplo da latência e triplo da taxa de falhas.

A abordagem verdadeiramente ideal é usar ferramentas construídas para um propósito que sejam rápidas e focadas.

Por exemplo, um Playwright CLI que leva apenas 100 milissegundos para cada operação de navegador; não um Chrome MCP que leva 15 segundos para fazer uma captura de ecrã → encontrar → clicar → esperar → ler. O primeiro é 75 vezes mais rápido.

O software moderno já não precisa ser "excessivamente projetado." O que deve fazer é: construir apenas o que realmente precisa e nada mais.

3. Resolver

Um resolver é essencialmente uma tabela de roteamento de contexto. Quando ocorre o tipo de tarefa X, o documento Y é carregado como prioridade. As competências dizem ao modelo "como fazer"; os resolvers dizem ao modelo "quando carregar o que".

Por exemplo, um desenvolvedor altera um determinado prompt. Sem um resolver, ele pode simplesmente terminar a alteração e lançá-la imediatamente. Com um resolver, o modelo leria primeiro o docs/EVALS.md. Este documento diria: execute primeiro a suíte de avaliação, compare os resultados antes e depois; se a precisão cair mais de 2%, reverta e investigue a razão. Este desenvolvedor pode nem ter sabido da existência da suíte de avaliação. É o resolver que carrega o contexto certo no momento certo.

O Claude Code vem com um resolver embutido. Cada competência tem um campo de descrição, e o modelo combina automaticamente a intenção do utilizador com a descrição da competência. Nem precisa de se lembrar se a competência /ship existe— a própria descrição é o resolver.

Para ser honesto, o meu anterior CLAUDE.md tinha impressionantes 20.000 linhas. Cada peculiaridade, cada padrão, cada lição que aprendi estava condensada nele. Totalmente absurdo. A qualidade da atenção do modelo diminuiu significativamente. O Claude Code até me disse diretamente para me livrar disso.

A correção final tinha provavelmente apenas 200 linhas—mantendo apenas alguns apontadores de documentos. Deixe o resolver carregar o documento necessário no momento crucial. Desta forma, 20.000 linhas de conhecimento podem ainda ser acedidas quando necessário, sem poluir a janela de contexto.

4. Latente e Determinístico

No seu sistema, cada passo está nesta categoria ou naquela. E confundir estes dois é o erro mais comum no design de agentes.

· O espaço latente é onde reside a inteligência. O modelo lê, compreende, julga e decide aqui. Trata-se de: julgamento, síntese, reconhecimento de padrões.

· O determinístico é onde reside a fiabilidade. Mesma entrada, sempre a mesma saída. Consultas SQL, código compilado, operações aritméticas pertencem todos a este lado.

Um único LLM pode ajudá-lo a colocar 8 pessoas à mesa para um jantar, tendo em conta a personalidade e a dinâmica social de cada pessoa. Mas se lhe pedir para colocar 800 pessoas, ele gerará sinceramente um gráfico de assentos "aparentemente razoável, mas na verdade completamente errado". Porque já não se trata de um espaço potencial que precisa de ser gerido, mas de um problema determinístico que foi forçosamente comprimido no espaço latente—um problema de otimização combinatória.

Os piores sistemas deslocam sempre o trabalho para um dos lados desta fronteira. Os melhores sistemas, no entanto, delinearão claramente a fronteira.

5. Diarização (Agrupamento de Documentos / Retrato de Tópicos)

Este passo de diarização é o que realmente confere à IA a capacidade de produzir valor ao trabalhar com conhecimento do mundo real.

Significa: o modelo lê todos os materiais relacionados a um tópico e, em seguida, produz um retrato estruturado. Condensar julgamentos de dezenas ou até centenas de documentos numa única página.

Isto não é algo que uma consulta SQL possa produzir. Nem é algo que um pipeline RAG possa produzir. O modelo deve realmente ler, manter informações contraditórias em mente simultaneamente, notar o que mudou, quando mudou, e depois sintetizar esses conteúdos em inteligência estruturada.

Esta é a diferença entre uma consulta de base de dados e um briefing de analista.

Esta Arquitetura

Estes cinco conceitos podem ser combinados numa arquitetura muito simples de três camadas.

· A camada superior é Fat Skills: processos escritos em markdown, contendo julgamentos, metodologias e conhecimento de domínio. 90% do valor reside nesta camada.
· A camada do meio é um harness CLI fino: cerca de 200 linhas de código, aceitando entrada JSON, produzindo saída de texto, com padrão de apenas leitura.
· A camada inferior é o seu sistema de aplicação: QueryDB, ReadDoc, Search, Timeline—estes são infraestruturas determinísticas.

O princípio orientador é direcional: empurrar "inteligência" o mais alto possível nas competências; empurrar "execução" o mais baixo possível nas ferramentas determinísticas; manter o harness leve.

O resultado é: cada vez que as capacidades do modelo melhoram, todas as competências tornam-se automaticamente mais fortes; enquanto os sistemas determinísticos fundamentais permanecem estáveis e fiáveis.

Sistemas de Aprendizagem

Abaixo, irei usar um sistema real que estamos a construir na YC para mostrar como estas cinco definições funcionam em conjunto.

Em Julho de 2026, Chase Center. A Startup School tem 6000 fundadores presentes. Todos têm materiais de candidatura estruturados, respostas a questionários, transcrições de conversas de mentoria 1:1 e sinais públicos: publicações no X, histórico de commits no GitHub e uso do Claude Code (indicando a sua velocidade de desenvolvimento).

A abordagem tradicional é que uma equipa de projeto de 15 pessoas leia as candidaturas uma a uma, faça julgamentos intuitivos e depois atualize uma folha de cálculo.

Este método pode funcionar com 200 pessoas, mas falha completamente com 6000 pessoas. Nenhum ser humano consegue manter tantos perfis na sua mente e perceber que a infraestrutura do agente de IA sugere os três principais candidatos para a direção: o fundador de uma ferramenta de desenvolvimento em Lagos, um empreendedor de conformidade em Singapura e um desenvolvedor de ferramentas CLI em Brooklyn—cada um dos quais, em diferentes conversas 1:1, descreveu o mesmo ponto de dor utilizando expressões completamente diferentes.

O modelo consegue fazê-lo. Aqui está como:

Enriquecimento

Existe uma habilidade chamada /enrich-founder, que extrai de todas as fontes de dados, realiza enriquecimento, diarização e destaca a diferença entre "o que o fundador disse" e "o que ele está realmente a fazer."

O sistema determinístico subjacente lida com: Consultas SQL, dados do GitHub, testes de navegador de URLs de demonstração, extração de sinais sociais, consultas CrustData, etc. Uma tarefa agendada é executada uma vez por dia. Os perfis de 6000 fundadores estão sempre atualizados.

A saída da diarização pode capturar informações que pesquisas por palavras-chave nunca conseguiriam encontrar:

Fundador: Maria Santos Empresa: Contrail (contrail.dev) Auto-descrição: "Datadog para agente de IA" Atividade real: 80% dos commits de código estão focados no módulo de faturamento → Essencialmente a construção de uma ferramenta de FinOps disfarçada como uma ferramenta de observabilidade

Esta diferença entre "o que é dito e o que é feito" requer a leitura simultânea dos históricos de commits do GitHub, materiais de candidatura e registos de conversação, integrando-os mentalmente. Nenhuma pesquisa de similaridade de embedding ou filtragem por palavras-chave consegue alcançar isto. O modelo deve ler na íntegra e depois fazer julgamentos. (Esta é exatamente o tipo de tarefa que deveria estar no espaço latente!)

Correspondência

É aqui que "habilidade = invocação de método" brilha.

Com a mesma habilidade de correspondência, chamá-la três vezes pode resultar em estratégias completamente diferentes:

/correspondência-desagregação: Gerir 1200 pessoas, agrupar por domínio, grupo de 30 cada (incorporação + atribuição determinística)

/correspondência-almoço: Gerir 600 pessoas, "correspondência aleatória" entre domínios, 8 pessoas por mesa sem repetição — o LLM gera primeiro os tópicos, depois um algoritmo determinístico organiza os lugares

/correspondência-ao-vivo: Gerir participantes ao vivo no local, com base na incorporação do vizinho mais próximo, completar a correspondência 1-a-1 em 200ms, e excluir pessoas que já se encontraram

O modelo também pode fazer julgamentos que algoritmos de agrupamento tradicionais não conseguem alcançar:

"Tanto Santos como Oram pertencem à infraestrutura de IA, mas não estão em uma relação competitiva — Santos faz atribuição de custos, Oram faz orquestração. Devem ser colocados no mesmo grupo."
"A aplicação de Kim mencionou ferramentas para desenvolvedores, mas a conversa 1:1 revelou que estão a trabalhar na automação da conformidade SOC2. Deve ser reclasificada sob FinTech / RegTech."

Este tipo de reclasificação é completamente ignorado pelas incorporações. O modelo deve ler todo o perfil.

Ciclo de Aprendizagem

Após o evento, uma habilidade /melhorar lê os resultados da pesquisa NPS, realiza diarização sobre os feedbacks categorizados como "ok, mas poderia ser melhor" — não críticas negativas, mas aquelas que estão quase lá — e extrai padrões.

Em seguida, propõe novas regras e as escreve de volta na habilidade de correspondência:

Quando um participante menciona "infraestrutura de IA," mas mais de 80% do seu código é para faturamento:
→ Classificado como FinTech, não como Infra de IA

Quando duas pessoas no mesmo grupo já se conhecem:
→ Reduzir o peso da correspondência
Priorizar a introdução de novas relações

Estas regras são escritas de volta para o ficheiro de competências. Elas entram em vigor automaticamente na próxima execução. As competências são "auto-editáveis." No evento de julho, as classificações de "ok, mas poderiam ser melhores" representaram 12%; no próximo evento, caiu para 4%.

O ficheiro de competências aprende o que "ok" significa, e o sistema melhora sem que ninguém reescreva o código.

Este padrão pode ser migrado para qualquer área:

Recuperar → Ler → Diarizar → Contar → Sintetizar

Então: Pesquisar → Investigar → Diarizar → Reescrever competência

Se me perguntassem qual é o ciclo mais valioso de 2026, seria este. Pode ser aplicado a quase qualquer cenário de trabalho de conhecimento.

A competência é uma Atualização Permanente

Recentemente, publiquei um comando para o OpenClaw no X, que recebeu uma resposta muito maior do que o esperado:

Prompt: Não é permitido fazer trabalho pontual. Se eu lhe pedir para fazer algo que se repetirá no futuro, deve: processar manualmente pela primeira vez de 3 a 10 amostras, mostrar-me os resultados; Se eu aprovar, transformá-lo num ficheiro de competências; Se deve ser executado automaticamente, adicioná-lo à tarefa agendada. O critério é: Se eu precisar perguntar uma segunda vez, você falhou.

Este conteúdo recebeu milhares de gostos e mais de dois mil favoritos. Muitas pessoas pensaram que isto era uma técnica de engenharia de prompts.

Na verdade, não é. É a arquitetura mencionada acima. Cada habilidade que você escreve é uma atualização permanente do sistema. Não irá degradar, não será esquecida. Irá funcionar automaticamente às três da manhã. E quando o modelo da próxima geração for lançado, todas as habilidades se tornarão instantaneamente mais fortes— a capacidade de julgamento da parte latente melhora, enquanto a parte determinística permanece estável e fiável.

É daqui que vem a eficiência 100x de Yegge.

Não de modelos mais inteligentes, mas de: Habilidades Espessas, Cinto Fino, e a disciplina de solidificar tudo em capacidades.

O sistema crescerá exponencialmente. Construa uma vez, execute a longo prazo.

[Link do Artigo Original]