Equipamento leve, habilidade avançada: A verdadeira fonte de um aumento de 100 vezes na produtividade com IA

Título original do artigo: Equipamento leve, grande habilidade
Autor do artigo original: Garry Tan
Tradução: Peggy, BlockBeats

Nota do editor: À medida que os “modelos mais robustos” se tornam a resposta padrão no setor, este artigo oferece uma perspectiva diferente: o que realmente amplia as diferenças de produtividade em 10, 100 ou até 1.000 vezes não é o modelo em si, mas todo o projeto do sistema construído em torno dele.

O autor deste artigo, Garry Tan, atual presidente e diretor executivo da Y Combinator, tem uma longa trajetória no campo da inteligência artificial e nos ecossistemas de startups em fase inicial. Ele apresenta a estrutura "fat skills + thin harness", dividindo as aplicações de IA em componentes-chave, tais como habilidades, estrutura de tempo de execução, roteamento de contexto, divisão de tarefas e compactação de conhecimento.

Nesse sistema, o modelo não representa mais a capacidade total, mas apenas uma unidade de execução dentro do sistema. O que realmente determina a qualidade do resultado é a forma como você organiza o contexto, consolida os processos e delimita a fronteira entre "inferência" e "cálculo".

Mais importante ainda, essa abordagem não é meramente conceitual, mas foi validada em cenários reais: diante de tarefas de processamento e correspondência de dados provenientes de milhares de empreendedores, o sistema atinge capacidades próximas às de analistas humanos por meio de um ciclo de “leitura-resumo-inferência-resposta”, otimizando-se continuamente sem a necessidade de reescrever o código. Esse "sistema de aprendizagem" transforma a IA de uma ferramenta pontual em uma infraestrutura com efeito cumulativo.

Assim, fica clara a mensagem central do artigo: na era da IA, as diferenças de eficiência não são mais determinadas pelo uso do modelo mais avançado, mas sim pela capacidade de construir um sistema que possa acumular recursos continuamente e evoluir automaticamente.

Segue-se o texto original:

Steve Yegge afirmou que aqueles que utilizam agentes de programação de IA são “de 10 a 100 vezes mais eficientes do que os engenheiros que programam apenas com o cursor e ferramentas de chat, e cerca de 1.000 vezes mais eficientes do que um engenheiro do Google de 2005”.

Nota: Steve Yegge é um engenheiro de software extremamente influente, blogueiro técnico e comentarista da cultura de engenharia no Vale do Silício, conhecido por seus artigos técnicos perspicazes, extensos e de opinião firme. Ele atuou como engenheiro sênior em empresas como a Amazon e o Google, passando posteriormente para a Salesforce, depois ingressando em startups da área de IA, além de ter sido um dos primeiros defensores do projeto Dart.

Isso não é exagero. Eu vi com meus próprios olhos e vivenciei em primeira mão. No entanto, quando as pessoas ouvem falar dessa lacuna, muitas vezes atribuem-na a fatores errados: um modelo mais potente, um Claude mais inteligente, mais parâmetros.

Na verdade, tanto a pessoa que é duas vezes mais eficiente quanto aquela que é cem vezes mais eficiente estão usando o mesmo modelo. A diferença não está na “inteligência”, mas na “arquitetura”, e essa arquitetura é tão simples que cabe em um cartão de anotações.

O Harness (Estrutura de Execução) é o próprio produto.

Em 31 de março de 2026, em uma reviravolta inesperada, a Anthropic divulgou acidentalmente o código-fonte completo do Claude Code no npm — totalizando 512.000 linhas. Li tudo. Isso confirmou algo de 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 projetadas para tarefas específicas, compressão máxima do contexto redundante, memória de sessão estruturada, subagentes em execução paralela — nada disso torna o modelo mais inteligente. Mas eles podem fornecer ao modelo o "contexto certo" no "momento certo", evitando ao mesmo tempo serem sobrecarregados por informações irrelevantes.

Essa camada de encapsulamento é chamada de harness (estrutura de execução). E a verdadeira pergunta que todos os desenvolvedores de IA deveriam fazer é: O que deve ser incluído no chicote elétrico e o que deve ficar de fora?

Curiosamente, essa pergunta tem uma resposta bem específica: um arnês fino, muita habilidade.

Cinco definições

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

Eles falham porque não compreendem seus dados — seu esquema, seus acordos, a forma que seu problema assume. E as cinco definições a seguir foram elaboradas precisamente para abordar essa questão.

1. Perfil de Habilidades

Um arquivo de habilidade é um documento Markdown reutilizável que ensina ao modelo "como fazer algo". Observe que ele não diz ao programa “o que fazer” — essa parte fica a cargo do usuário. O arquivo de habilidades descreve o processo.

O ponto principal que a maioria das pessoas ignora é o seguinte: um arquivo de habilidade é, na verdade, como uma chamada de método. Ela pode receber parâmetros. Você pode chamá-la com diferentes parâmetros. O mesmo processo, quando executado com entradas diferentes, pode demonstrar capacidades muito distintas.

Por exemplo, existe uma habilidade chamada /investigate. Consiste em sete etapas: Definir o escopo dos dados, traçar uma linha do tempo, catalogar cada documento, sintetizar, apresentar argumentos de ambos os lados, citar fontes. Aceita três parâmetros: META, PERGUNTA e CONJUNTO DE DADOS.

Se você direcionar isso a um especialista em segurança e a 2,1 milhões de e-mails forenses, ele se transformará em um analista de pesquisa médica para determinar se um denunciante foi silenciado.

Se você direcionar essa ferramenta para uma empresa de fachada e para os registros de divulgação da Comissão Eleitoral Federal (FEC), ela se transformará em um investigador forense especializado em litígios para rastrear doações políticas coordenadas.

A mesma habilidade. Os mesmos sete passos. O mesmo arquivo Markdown. A função descreve um processo de tomada de decisão, e o que realmente a torna operacional são os parâmetros de entrada durante a execução.

Isso não é engenharia de prompt, mas sim design de software: só que, neste caso, o Markdown é a linguagem de programação e o julgamento humano é o ambiente de execução. Na verdade, o Markdown é ainda mais adequado para a encapsulação do que o código-fonte rígido, pois descreve o processo, o julgamento e o contexto — que, por acaso, são a linguagem que o modelo compreende melhor.

2. Harness (Estrutura de Execução)

O Harness é a camada de software que controla o funcionamento do LLM. Ele faz apenas quatro coisas: executa o modelo em um loop, lê e grava seus arquivos, gerencia o contexto e aplica restrições de segurança.

É isso aí. Isso é "magro".

O padrão oposto é: muita aparência, pouca habilidade.

Você provavelmente já viu isso: mais de 40 definições de ferramentas, em que só a documentação ocupa metade da tela; uma ferramenta “toda-poderosa” que leva de 2 a 5 segundos para fazer uma viagem de ida e volta ao Gerador de Dados Controláveis; ou encapsular cada endpoint de uma API REST em uma ferramenta separada. O resultado é o triplo do uso de tokens, o triplo da latência e o triplo da taxa de falhas.

A abordagem realmente ideal é utilizar ferramentas desenvolvidas especificamente para esse fim, que sejam rápidas e tenham um foco bem definido.

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

Os softwares modernos já não precisam ser "excessivamente complexos". O que você deve fazer é: construir apenas o que realmente precisa e nada mais.

3. Resolver

Um resolvedor é, essencialmente, uma tabela de roteamento contextual. Quando ocorre o tipo de tarefa X, o documento Y é carregado com prioridade. As habilidades indicam ao modelo "como fazer"; os resolvedores indicam ao modelo "quando carregar o quê".

Por exemplo, um desenvolvedor altera um determinado prompt. Sem um responsável pela resolução, eles poderiam simplesmente concluir a alteração e lançá-la imediatamente. Com um resolvedor, o modelo leria primeiro o arquivo docs/EVALS.md. Este documento indicaria: execute primeiro o conjunto de testes de avaliação, compare as pontuações antes e depois; se a precisão cair mais de 2%, reverta as alterações e investigue o motivo. É possível que esse desenvolvedor nem soubesse da existência do conjunto de testes de avaliação. É o resolvedor que carrega o contexto correto no momento certo.

O Claude Code vem com um resolvedor integrado. Cada habilidade possui um campo de descrição, e o modelo associa automaticamente a intenção do usuário à descrição da habilidade. Você nem precisa se lembrar se a habilidade /ship existe — a própria descrição é o que resolve a questão.

Para ser sincero, meu CLAUDE.md anterior tinha nada menos que 20.000 linhas. Cada peculiaridade, cada padrão, cada lição que eu havia aprendido estava concentrada ali. Um absurdo total. A qualidade da atenção do modelo diminuiu significativamente. Claude Code chegou a me dizer diretamente para me livrar disso.

A correção final provavelmente teve apenas 200 linhas — mantendo apenas alguns ponteiros de documentos. Deixe que o resolvedor carregue o documento necessário no momento certo. Dessa forma, ainda é possível acessar 20.000 linhas de código quando necessário, sem sobrecarregar a janela de contexto.

4. Latente e determinístico

No seu sistema, cada etapa se enquadra nesta ou naquela categoria. E confundir esses dois é o erro mais comum no projeto de agentes.

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

· A confiabilidade reside na determinismo. A mesma entrada, sempre a mesma saída. Consultas SQL, código compilado e operações aritméticas fazem parte desse lado.

Um único LLM pode ajudar você a organizar os lugares para oito pessoas em um jantar, levando em conta a personalidade de cada um e a dinâmica social. Mas se você pedir para acomodar 800 pessoas, ele irá gerar, sem pestanejar, um plano de lugares que “parece razoável, mas na verdade está completamente errado”. Porque já não se trata de um espaço potencial que precisa ser tratado, mas de um problema determinístico que foi forçado a caber no espaço latente — um problema de otimização combinatória.

Os piores sistemas sempre classificam erroneamente os trabalhos de ambos os lados dessa fronteira. Os melhores sistemas, no entanto, delimitarão claramente essa fronteira.

5. Diarização (Agrupamento de documentos / Retrato temático)

Essa etapa de diarização é o que realmente confere à IA a capacidade de gerar valor ao trabalhar com conhecimento do mundo real.

Isso significa que o modelo analisa todos os materiais relacionados a um tema e, em seguida, produz um resumo estruturado. Resumir o conteúdo de dezenas ou até centenas de documentos em uma única página.

Isso não é algo que uma consulta SQL possa gerar. Também não é algo que um pipeline RAG possa produzir. O modelo deve, de fato, ler, manter informações contraditórias em mente simultaneamente, observar o que mudou e quando mudou e, em seguida, sintetizar esses conteúdos em conhecimento estruturado.

Essa é a diferença entre uma consulta a um banco de dados e uma apresentação do analista.

Esta arquitetura

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

· A camada superior é a Fat Skills: processos escritos em Markdown, que contêm avaliações, metodologias e conhecimento específico da área. 90% do valor está nesta camada.
· A camada intermediária é uma pequena estrutura CLI: cerca de 200 linhas de código, que recebe entradas em JSON e gera saídas em texto, sendo configurada por padrão como somente leitura.
· A camada inferior é o seu sistema de aplicativos: QueryDB, ReadDoc, Search, Timeline — trata-se de uma infraestrutura determinística.

O princípio orientador é direcional: elevar a “inteligência” o máximo possível no âmbito das competências; transferir a “execução” o mais para baixo possível, para ferramentas determinísticas; manter a estrutura leve.

O resultado é o seguinte: sempre que as capacidades do modelo melhoram, todas as habilidades se tornam automaticamente mais fortes; enquanto os sistemas determinísticos fundamentais permanecem estáveis e confiáveis.

Sistemas de Aprendizagem

A seguir, vou usar um sistema real que estamos desenvolvendo na YC para mostrar como essas cinco definições funcionam em conjunto.

Em julho de 2026, no Chase Center. A Startup School conta com 6.000 fundadores inscritos. Todos têm documentos de candidatura estruturados, respostas a questionários, transcrições de conversas individuais com mentores e sinais públicos: publicações no X, histórico de commits no GitHub e uso do Claude Code (indicando sua velocidade de desenvolvimento).

A abordagem tradicional consiste em uma equipe de projeto de 15 pessoas ler as inscrições uma a uma, fazer avaliações intuitivas e, em seguida, atualizar uma planilha.

Esse método pode funcionar com 200 pessoas, mas falha completamente com 6.000 pessoas. Nenhum ser humano consegue reter tantos perfis na memória e perceber que a infraestrutura do agente de IA sugere os três principais candidatos para orientação: o fundador de uma ferramenta de desenvolvimento em Lagos, um empreendedor da área de conformidade em Cingapura e um desenvolvedor de ferramentas CLI no Brooklyn — cada um deles, em diferentes conversas individuais, descreveu o mesmo ponto fraco usando expressões completamente diferentes.

A modelo consegue fazer isso. Veja como:

Enriquecimento

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

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

O resultado da diarização pode capturar informações que as pesquisas por palavras-chave nunca conseguiriam encontrar:

Fundador: Empresa Maria Santos: Contrail (contrail.dev) Descrição do próprio projeto: "Datadog para o agente de IA" Atividade real: 80% das atualizações de código concentram-se no módulo de faturamento → Basicamente, estamos desenvolvendo uma ferramenta de FinOps disfarçada de ferramenta de observabilidade

Essa diferença entre “o que se diz e o que se faz” exige a leitura simultânea dos históricos de commits do GitHub, dos materiais de candidatura e dos registros de conversas, além de integrá-los mentalmente. Nenhuma pesquisa de similaridade por incorporação ou filtragem por palavra-chave consegue alcançar isso. O modelo deve ler o texto na íntegra e, em seguida, formular conclusões. (Esse é exatamente o tipo de tarefa que deveria estar no espaço latente!)

Correspondência

É aqui que a equação "habilidade = invocação de método" se destaca.

Mesmo com a mesma habilidade de combinação, chamá-la três vezes pode resultar em estratégias completamente diferentes:

/match-breakout: Processar 1.200 pessoas, agrupando por domínio, em grupos de 30 cada (incorporação + atribuição determinística)

/almoço-pós-jogo: Gerenciar 600 pessoas, “emparelhamento aleatório” entre domínios, 8 pessoas por mesa sem repetições — o LLM gera primeiro os tópicos, e depois um algoritmo determinístico organiza os lugares

/match-live: Gerenciar participantes presenciais em tempo real, com base na incorporação de vizinhos mais próximos, concluir a correspondência individual em até 200 ms e excluir pessoas que já se conheceram

O modelo também é capaz de tomar decisões que os algoritmos tradicionais de agrupamento não conseguem realizar:

"Tanto a Santos quanto a Oram fazem parte da infraestrutura de IA, mas não estão em relação de concorrência — a Santos lida com a atribuição de custos, enquanto a Oram lida com a orquestração." "Devem ser colocados no mesmo grupo."
"A candidatura de Kim mencionava ferramentas de desenvolvimento, mas a conversa individual revelou que eles estão trabalhando na automação da conformidade com a SOC 2." Deve ser reclassificado na categoria FinTech / RegTech.

Esse tipo de reclassificação passa completamente despercebido pelas representações de embedding. O modelo deve ler o perfil inteiro.

Ciclo de aprendizagem

Após o evento, uma habilidade /improve analisa os resultados da pesquisa NPS, realiza a diáriação dos comentários classificados como “bom, mas poderia ser melhor” — não as avaliações negativas, mas aquelas que estão quase lá — e extrai padrões.

Em seguida, propõe novas regras e as reincorpora à habilidade correspondente:

Quando um participante fala em "infraestrutura de IA", mas mais de 80% do seu código é destinado à cobrança:
→ Classificado como FinTech, e não como infraestrutura de IA

Quando duas pessoas do mesmo grupo já se conhecem:
→ Reduzir o peso da correspondência
Priorize o estabelecimento de novos relacionamentos

Essas regras são gravadas no arquivo da habilidade. Elas entram em vigor automaticamente na próxima execução. As habilidades consistem em "autoedição". No evento de julho, as avaliações do tipo “tudo bem, mas poderia ser melhor” representaram 12%; no evento seguinte, esse número caiu para 4%.

O arquivo de habilidades aprende o que significa “okay”, e o sistema fica melhor sem que ninguém precise reescrever o código.

Esse padrão pode ser aplicado a qualquer campo:

Recuperar → Ler → Registrar → Contar → Sintetizar

Então: Pesquisar → Investigar → Registrar → Habilidade de reescrever

Se alguém perguntasse qual é o loop mais valioso de 2026, seria este. Pode ser aplicado a praticamente qualquer situação de trabalho intelectual.

A habilidade é uma melhoria permanente

Recentemente, publiquei um comando no OpenClaw no X, que teve uma repercussão muito maior do que o esperado:

Sugestão: Não é permitido realizar trabalhos pontuais. Se eu pedir que você faça algo que se repetirá no futuro, você deve: processar manualmente de 3 a 10 amostras na primeira vez e me mostrar os resultados; se eu aprovar, transforme isso em um arquivo de habilidade; se for para ser executado automaticamente, adicione-o à tarefa agendada. O critério é: Se eu precisar perguntar uma segunda vez, você já falhou.

Este conteúdo recebeu milhares de curtidas e mais de duas mil marcações. Muitas pessoas achavam que essa era uma técnica de engenharia rápida.

Na verdade, não é. É a arquitetura mencionada acima. Cada habilidade que você registra é uma melhoria permanente no sistema. Não se deteriorará, não será esquecido. Isso será executado 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 confiável.

É daí que vem a eficiência 100 vezes maior de Yegge.

Não de modelos mais inteligentes, mas de: Competências sólidas, estrutura enxuta e a disciplina de transformar tudo em capacidades.

O sistema crescerá exponencialmente. Crie uma vez, use por muito tempo.

[Link para o artigo original]