Akshay Katyal publicou uma confissão neste mês. O time dele construiu uma biblioteca de skills para os agentes, viu o número crescer até 96 skills dentro de um único plugin, e então deletou 93 delas em um único pull request. Toda skill deletada tinha zero invocações nos 60 dias anteriores. A biblioteca havia virado algo que ninguém planejou e ninguém assumiu: um segundo código-fonte rodando em paralelo ao real, com todos os passivos de código e nenhuma das disciplinas.
A frase que vale guardar é dele. “Um catálogo que só cresce não é o bom sinal que parece ser.”
A maioria dos times lê um catálogo de skills em crescimento como tração. Mais skills, mais alavanca, mais conhecimento capturado. Os dados de Akshay dizem o contrário. Crescimento sem aposentadoria não é um sinal saudável. É dívida se acumulando num lugar onde suas ferramentas se recusam a olhar.
Um Segundo Código-Fonte Que Você Esqueceu de Governar
Quando você sobe código de aplicação, todo o aparato da engenharia de software se aplica. Controle de versão. Revisão de código. Testes. Linters. Ciclos de depreciação. Donos. Essa maquinaria existe porque todo mundo concorda que código apodrece e alguém precisa mantê-lo.
Uma biblioteca de skills também é código. Tem lógica, dependências, premissas sobre o mundo, e comportamento do qual outros sistemas dependem. Mas ela escapa do aparato. Skills entram por um PR rápido ou, com frequência, um único commit de um único autor. Akshay relata que, num marketplace compartilhado de mais de 600 skills espalhadas por cerca de 80 plugins, aproximadamente metade do catálogo é exatamente isso: um commit, um autor, nunca mais tocado.
Esse é o formato de um código-fonte sem governança. Escreve-uma-vez, revisa-de-leve, mantém-nunca. A diferença é que ninguém chama isso de código-fonte, então ninguém destina a ele o orçamento de manutenção que um código-fonte exige.
A Podridão Que Você Não Vê no Diff
Aqui está o que torna a degradação de skills genuinamente perigosa. Ela não aparece no histórico de versões.
Código de aplicação apodrece de forma visível. Uma função quebra porque alguém mudou quem a chama, e a mudança fica num commit que você pode apontar. Você consegue dar git blame na degradação. Com skills, o arquivo nunca muda. A skill que funcionava perfeitamente em março tem os mesmos bytes em junho. O que mudou foi tudo ao redor dela.
A API externa que a skill encapsula lançou uma nova versão. O modelo por baixo do agente ficou melhor e não precisa mais da mão segura que a skill oferece, ou pior, as instruções da skill agora brigam ativamente com os padrões aprimorados do modelo. O código-fonte sobre o qual a skill opera foi reorganizado, então os caminhos e convenções que ela presume estão silenciosamente errados. A degradação é real, e nada disso aparece no diff. O contexto da skill apodreceu enquanto a própria skill ficou parada.
Essa é a armadilha. Seus instintos normais para achar código velho dependem todos de mudança. Você olha o que foi modificado recentemente, o que tem churn, o que está lançando erros. Uma skill apodrecendo não dispara nenhum desses sinais. Ela só fica ali, completamente presente no contexto, consumindo tokens, empurrando o agente para instruções que não batem mais com a realidade. Escrevemos sobre degradação de código-fonte em desacelerar-degradacao-agentes. Esta é a irmã: o segundo código-fonte degrada do mesmo jeito, mas com ainda menos alarmes, porque o segundo código-fonte não tem suíte de testes vigiando.
Skills em Contexto São um Custo, Não uma Estante
Existe um modelo mental reconfortante que diz que skills não usadas são inofensivas. Ficam numa estante. Se ninguém chama, não custam nada. Pode ignorar.
Esse modelo está errado pela mesma razão que uma janela de contexto entupida está errada. Skills não ficam inertes numa estante. Os metadados delas carregam no contexto de trabalho do agente para que ele saiba que existem e quando recorrer a elas. Toda skill no catálogo é um pequeno imposto permanente sobre toda decisão que o agente toma sobre qual skill usar. Noventa e três skills mortas são noventa e três distrações que o agente precisa considerar e descartar. Como argumentamos em contexto-passivo-agentes-ia, o contexto que um agente carrega molda o comportamento dele, tenha você invocado de propósito ou não. Uma skill morta é contexto passivo com retorno negativo.
Então o catálogo que só cresce não é armazenamento gratuito. É um piso de ruído subindo. Cada adição torna o problema de seleção do agente marginalmente mais difícil, e o custo marginal fica invisível até o dia em que alguém mede invocações e descobre que 97 por cento da biblioteca é peso morto.
Ninguém Assume a Deleção
O problema mais profundo não é técnico. É sobre autoridade.
Criar uma skill é um ato celebrado. Alguém resolveu um problema, capturou a solução, e a tornou reutilizável. Há um nome no commit e uma pequena dose de crédito. Deletar uma skill é o oposto. É sem glamour, levemente arriscado (e se alguém precisava daquilo?), e não produz vitória visível. Então o lado da criação no balanço tem muitos autores ansiosos e o lado da deleção não tem nenhum.
É por isso que a deleção de 93 skills de Akshay é a história de fato, não um rodapé dela. Alguém teve que reivindicar a autoridade para deletar. Alguém teve que decidir que zero invocações em 60 dias significava que uma skill estava morta e que skills mortas vão embora. A maioria das organizações nunca atribui essa autoridade a ninguém, e é exatamente por isso que os catálogos delas só crescem. Um coletor de lixo não é uma pessoa que odeia skills. É a função que recupera o que não é mais alcançável. Runtimes de software automatizam isso porque gerência manual de memória é onde os vazamentos moram. Bibliotecas de skills não têm essa automação e, na maioria dos times, nenhum humano fazendo o papel também.
Como construir skills bem é um problema suficientemente resolvido. Como elas morrem, e quem assina o atestado do funeral, é o problema não resolvido. O lado da construção tem taxonomias, templates, e boas práticas. O lado da aposentadoria não tem nada, e é por isso que a aposentadoria não acontece.
Faça Isso Agora
Você não precisa de um framework. Precisa de um dono e de uma métrica.
Instrumente invocações. Se você não consegue responder “quantas vezes cada skill foi chamada nos últimos 60 dias”, está voando às cegas e todo passo seguinte é chute. Contar é barato. Comece por aí.
Nomeie o dono da deleção. Uma pessoa ou um papel detém a autoridade para aposentar skills, e aposentar uma skill morta é tratado como contribuição, não como perda. Coloque no mesmo patamar que criar uma.
Defina uma política padrão. O limiar de Akshay é um bom ponto de partida: zero invocações em 60 dias marca a skill para revisão, e o ônus da prova fica em mantê-la, não em removê-la. Revise a lista marcada num cronograma, não quando o catálogo finalmente doer.
Leia seu catálogo crescente da forma correta. Uma biblioteca de skills que só adiciona e nunca remove não é uma vitrine de troféus. É um segundo código-fonte acumulando dívida que seu diff nunca vai te mostrar, até alguém rodar os números e deletar 93 coisas de uma vez.
Fontes
- Akshay Katyal. “We Accidentally Built a Second Codebase.” Junho de 2026.
A Victorino ajuda times a dar ciclo de vida e dono às suas bibliotecas de skills de agentes: contato@victorino.com.br | www.victorino.com.br
Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →
Se isso faz sentido, vamos conversar
Ajudamos empresas a implementar IA sem perder o controle.
Agendar uma Conversa