O que Garry Tan entendeu sobre IA não foi como programar melhor. Foi como organizar melhor o trabalho.

A discussão sobre IA no desenvolvimento de software costuma cair em dois extremos. De um lado, quem trata agentes como brinquedo inflado de hype. Do outro, quem fala como se uma nova civilização estivesse sendo fundada dentro do terminal.

Garry Tan conseguiu provocar as duas reações ao mesmo tempo.

O pacote gstack reúne um conjunto de skills e prompts pensados pra fazer a IA atuar em diferentes papéis dentro do processo de desenvolvimento: CEO, engenheiro, revisor de código, designer, redator de documentação. À primeira vista, muita gente olhou pra isso e resumiu: "é só um monte de prompts."

Mas esse pode ser justamente o erro de leitura.

O ponto não é o prompt. É a estrutura.

Quando alguém vê o gstack e pensa "isso eu também faria", pode até estar certo no nível técnico. O problema é que essa resposta ignora a parte mais importante da proposta: o valor não está em cada instrução isolada, mas no modo como elas são organizadas.

A sacada não é ter inventado mágica escondida dentro do Claude Code. É ter tratado a IA não como um bloco único de execução, mas como uma equipe operacional distribuída em funções. Em vez de pedir tudo de uma vez pra um único agente, o fluxo divide o trabalho em responsabilidades específicas.

Na prática, isso aproxima a interação com IA de uma lógica mais madura de engenharia: etapas, especialização, revisão, documentação, crítica e refinamento.

É menos "me construa isso"
e mais "vamos estruturar como isso deve ser construído."

Por que tanta gente gostou

O projeto viralizou porque tocou num ponto real da experiência de quem já trabalha com ferramentas de IA pra código: não basta ter um modelo bom; é preciso ter um fluxo bom.

Muita gente ainda usa IA como se estivesse lidando com um estagiário super-rápido: joga uma tarefa grande, espera o resultado e torce pra sair algo usável. Os melhores resultados aparecem quando existe uma arquitetura de trabalho por trás da interação.

É aí que o gstack ganha força. Ele não oferece apenas respostas. Ele sugere um processo.

E por que tanta gente odiou

Porque o hype em torno de IA está num ponto em que qualquer exagero gera reação imediata.

Quando Garry Tan descreveu o setup como quase um "god mode" e relatou que ele havia ajudado a descobrir uma falha de segurança que uma equipe não teria percebido, muita gente viu ali mais do que entusiasmo. Viu o padrão típico do momento: executivos tratando workflows úteis como revelações messiânicas.

A crítica não é totalmente injusta. Existe hoje uma tendência bem visível de transformar qualquer ganho incremental em linguagem de ruptura absoluta. Quando tudo vira revolução, fica mais difícil separar avanço real de performance pública de empolgação.

Pra muita gente, o projeto não parecia uma descoberta extraordinária — parecia uma embalagem mais visível de práticas que usuários avançados já vinham testando por conta própria. Honestamente, há verdade nisso também.

O erro dos dois lados

Os entusiasmados demais confundem workflow inteligente com milagre técnico. Os críticos apressados confundem familiaridade com irrelevância.

Nem tudo que pode ser reproduzido facilmente é banal. Muitas vezes, o valor de uma ideia está em torná-la legível, replicável e organizada o suficiente pra outras pessoas conseguirem usar. Esse tipo de trabalho é subestimado porque não parece genial no sentido tradicional — não inventa um novo modelo, não publica uma arquitetura inédita. Mas pode mudar a forma como pessoas trabalham no dia a dia.

E adoção prática costuma importar mais do que brilho conceitual.

O que esse episódio realmente revela

Durante muito tempo, a conversa sobre IA em software girou em torno de capacidade bruta: qual modelo programa melhor, qual ferramenta erra menos, qual benchmark saiu na frente.

A próxima camada da disputa parece estar mudando de lugar. A pergunta agora é outra:

Quem sabe desenhar melhor o sistema de trabalho ao redor da IA?

Conforme os modelos ficam mais competentes, o diferencial deixa de estar apenas no motor e aparece cada vez mais no método. Não é só ter acesso ao melhor agente. É saber:

• quando pedir
• em que ordem pedir
• com que papel pedir
• como revisar e iterar
• como transformar respostas soltas em processo consistente

IA como time, não como truque

Se existe uma ideia forte por trás do gstack, é essa: talvez o futuro do desenvolvimento assistido por IA não pareça uma conversa única com um gênio universal.

Talvez ele se pareça mais com a coordenação de múltiplos papéis, múltiplas camadas de revisão e múltiplos ciclos de decisão. Menos oráculo, mais organização.

Isso explica por que tanta gente olhou pro projeto e, ao mesmo tempo, pensou duas coisas aparentemente contraditórias: "isso não é tão novo assim" e "isso é exatamente o tipo de coisa que eu quero copiar."

E talvez ambas estejam certas.

O gstack pode não ser uma revolução técnica.

Mas também não é só um punhado qualquer de prompts.

Ele funciona como sinal de uma transição importante: a maturidade no uso de IA talvez não venha apenas de modelos melhores, mas de estruturas melhores de trabalho.

Porque o valor da IA no software não está apenas em escrever código mais rápido.
Está em criar um processo onde pensar, revisar, testar, criticar e documentar também podem escalar.