Garry Tan publica seu Claude Code: 23 ferramentas-papel e 139 mil estrelas

Cena familiar: você pede a um agente de IA para "fazer uma funcionalidade" e, num único fluxo, ele inventa o produto, desenha a interface, escreve o código, se elogia e esquece da documentação. O resultado costuma ser medíocre em todos os itens. O repositório garrytan/gstack tenta curar justamente isso e hoje volta a aparecer no top diário do GitHub Trending: 139.039 estrelas no total e 285 nas últimas 24 horas.

O que é este conjunto

Garry Tan apresenta o gstack como seu ajuste fino do Claude Code. A descrição do projeto diz que são 23 ferramentas "opinativas" (opinionated) que funcionam como CEO, designer, gerente de engenharia, gerente de lançamentos, engenheiro de documentação e QA. A linguagem do projeto é TypeScript.

Uma ressalva importante: nos baseamos na descrição do repositório e em suas métricas. Uma análise linha a linha de cada uma das 23 ferramentas não é apresentada aqui, e vale fazê-la por conta própria antes de adotar o conjunto.

Por que papéis funcionam melhor do que um prompt geral

A lógica é simples e familiar para quem já montou uma equipe. Quando uma só pessoa responde tanto pela decisão de produto quanto pela verificação de qualidade, ela tende a concordar consigo mesma. Com um modelo de linguagem é igual: se, no mesmo contexto, ele escreve o código e o avalia, a crítica sai branda.

Imagine um dia típico. Você quer adicionar uma tela de configurações a um serviço. Em um esquema por papéis, a ordem pode ser esta:

• o "CEO" verifica se a funcionalidade é realmente necessária e o que há de mais importante nela;
• o "designer" descreve os estados da tela e os casos de borda;
• o "gerente de engenharia" divide a tarefa em etapas;
• o "QA" tenta, separadamente, quebrar o resultado;
• o "gerente de lançamentos" e o "editor de documentação" resolvem as pontas soltas: a versão, a lista de mudanças, o README.

Cada papel recebe suas próprias instruções e seus próprios critérios de sucesso. Não é mágica, mas disciplina de processo embutida nas ferramentas, para não precisar guardá-la de cabeça nem reescrever o prompt a cada vez.

Por que isso está em discussão

O primeiro motivo é óbvio: o nome do autor. Quando o chefe de uma grande aceleradora de startups mostra exatamente como trabalha com um agente, isso é interessante como artefato de trabalho, e não como teoria. O segundo motivo é mais profundo: a comunidade está cansada de conversas abstratas sobre agentes e quer ver configurações concretas que possam ser copiadas e executadas.

As estrelas, porém, devem ser lidas com cuidado. 139 mil indicam atenção e curiosidade, mas não produtividade comprovada. A popularidade de um repositório não substitui medições na sua própria base de código.

Limitações

A descrição diz honestamente que as ferramentas são "opinativas". Isso significa que há gostos alheios embutidos: como deve ser um bom lançamento, o que se considera documentação suficiente, quão rígido deve ser o QA. Para uma equipe com outra stack, outras convenções ou exigências regulatórias, parte das regras terá de ser reescrita.

Há também um custo oculto: mais papéis significam mais chamadas ao modelo, mais tokens e mais pontos em que algo pode dar errado. Se o seu projeto é pequeno, 23 ferramentas podem ser demais, e duas ou três bastam.

O que fazer na prática

Não instale o conjunto inteiro num repositório de trabalho logo no primeiro dia. É melhor assim:

• clone o projeto e leia as instruções dos papéis: é um manual gratuito sobre como estruturar o trabalho de um agente;
• experimente dois papéis com o benefício mais claro, por exemplo QA e documentação;
• execute-os numa tarefa pequena e compare o resultado com o seu método habitual;
• guarde o que funcionou e descarte o resto.

Gerentes de produto e fundadores devem olhar o gstack de outro ângulo: como um modelo de processo. Mesmo que você não use o código em si, a pergunta "quais papéis no meu desenvolvimento com agente ninguém desempenha ainda" é útil. Na maioria das vezes, são justamente o controle de qualidade e a higiene de lançamentos.

A principal conclusão: o valor do gstack não está em ser o "melhor setup", mas em mostrar como é um trabalho maduro com um agente de código: papéis, regras e divisão de responsabilidades em vez de um único prompt longo.