Get-shit-done: quais erros de vibe coding o sistema GSD corrige?

Fala aí, beleza? Tem uma cena que todo mundo que programa conversando com IA já viveu: você pede uma feature, o agente devolve o arquivo inteiro em segundos e aí você passa o resto do dia consertando o que ele entregou

A entrega foi rápida

o problema é que ela voltou pra sua mesa

O get-shit-done (GSD) nasceu bem nesse ponto de dor: o projeto original é um sistema de meta-prompting, engenharia de contexto e desenvolvimento orientado a spec para Claude Code, publicado por TÂCHES no repositório gsd-build/get-shit-done

Hoje ele segue como GSD Core, mantido pela comunidade, e o alcance cresceu: roda em vários runtimes de agente de código, não só no Claude Code (já já eu detalho isso)

Neste post eu mapeio os vícios típicos do vibe coding, um por um, e mostro qual resposta o sistema dá pra cada um deles

Bora ver? 🙂

O que é o get-shit-done e onde ele vive hoje

Primeiro o mapa, porque esse projeto tem duas casas e isso confunde muita gente

O repositório original, gsd-build/get-shit-done, foi arquivado pelo dono em 26/06/2026 e está somente leitura

O desenvolvimento continua como GSD Core, no open-gsd/gsd-core, uma continuação mantida pela comunidade a partir do trabalho publicado por TÂCHES

A discussão de abertura do fork conta o motivo: não há contato com o mantenedor original desde 01/04/2026, e as contas sociais dele aparecem deletadas ou inacessíveis

Ou seja: se você for contribuir, é no repositório novo, não no arquivado

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

E o que dá pra usar hoje?

A release mais recente listada no GitHub é a v1.11.0, de 19/08/2026

A instalação sai por npx, a partir do pacote @opengsd/gsd-core, e o instalador pergunta qual runtime você usa e se a instalação é global ou local:

npx @opengsd/gsd-core@latest

Dá pra já responder isso na linha de comando, por exemplo pra Claude Code em escopo global:

npx @opengsd/gsd-core@latest --claude --global

Depois de instalado, o comando de entrada é /gsd-new-project

E se liga nisso: o GSD Core roda como suítes de skills e comandos em vários runtimes de agente de código, não só no Claude Code

A lista de suportados inclui Claude Code, Codex, Antigravity CLI, Kimi CLI, Copilot, Cursor, Windsurf e Kilo

Se o teu problema ainda é mais embaixo, tipo Node velho e permissão do npm atrapalhando, aqui no blog tem um post só sobre erros ao instalar o Claude Code que resolve essa parte antes

Os cinco vícios do vibe coding e a resposta do GSD

Agora a parte central

Cada vício aqui embaixo segue o mesmo formato: o sintoma (o que você percebe na prática), a causa (por que acontece), a resposta do GSD e como prevenir mesmo que você não instale nada

Antes de entrar neles, o desenho geral: cada milestone do GSD Core repete um loop de cinco etapas, uma fase por vez

• Discuss: capturar decisões antes de planejar
• Plan: pesquisar, decompor e verificar se o plano cabe numa janela de contexto nova
• Execute: rodar planos em ondas paralelas
• Verify: revisar o que foi construído, diagnosticar e corrigir
• Ship: abrir o PR, arquivar a fase e seguir pra próxima

Guarda esse loop na cabeça, porque cada vício abaixo cai em uma dessas etapas

1. A sessão que vai piorando quanto mais você fala com ela

Sintoma: no começo do dia o agente acerta de primeira, no fim da tarde ele esquece uma decisão que vocês combinaram lá atrás na conversa e reescreve um arquivo que já estava certo

Causa: é o que o GSD Core chama de context rot, a degradação que se acumula conforme o agente enche a janela de contexto, com o recall enfraquecendo e o raciocínio piorando

Não é preguiça do modelo, é a janela lotada cobrando o preço

Resposta do GSD: o trabalho pesado (pesquisa, planejamento e execução) roda em subagentes com contexto fresco, mantendo a sessão principal enxuta

Cada executor começa com uma janela limpa de 200.000 tokens

O /gsd-execute-phase leva isso ao pé da letra: ele descobre os arquivos de plano da fase, analisa dependências, agrupa em ondas paralelas e dispara um executor novo por plano, com commit atômico por executor antes da onda seguinte

Como prevenir sem o sistema: pare de tratar a conversa como o projeto

Fatie o trabalho em unidades que cabem numa sessão nova, e escreva a decisão em arquivo antes que a janela encha

2. O prompt vago (o erro mais caro de todos)

Sintoma: você pede "faz a tela de login" e recebe uma tela de login… só que sem a validação que você tinha na cabeça, com um fluxo que você não pediu e um campo a mais

Causa: a documentação do GSD Core é bem direta nisso: engenharia de contexto sozinha não basta

Se o agente começa do zero mas recebe instrução vaga, a saída é vaga

Contexto limpo não conserta pedido torto

Resposta do GSD: o pareamento contexto fresco mais especificação estruturada

O PLAN.md quebra o trabalho em tarefas discretas, ordenadas por dependência e com critérios de aceitação explícitos, pra que o executor trabalhe sobre especificação e não sobre reinterpretação de conversa

Sacou a diferença? Uma coisa é o agente adivinhar o que "pronto" significa, outra é ele ler o que "pronto" significa

Como prevenir sem o sistema: antes de mandar o prompt, escreva em duas linhas como você vai saber que aquilo está certo

Se você não consegue escrever isso, o agente também não consegue acertar, e é aí que nascem os erros de quem programa com IA que viraram piada na timeline

3. A decisão que nunca foi capturada

Sintoma: no meio da execução o agente escolhe por você: um banco, um formato de resposta, um jeito de tratar erro

Você só descobre a escolha quando ela já está espalhada por cinco arquivos

Causa: ninguém separou o momento de decidir do momento de executar

A decisão foi tomada dentro do código, não antes dele

Resposta do GSD: a etapa Discuss existe justamente pra capturar decisões antes de planejar

Depois, no /gsd-plan-phase, entram subagentes especializados num loop de revisão: o gsd-phase-researcher investiga o domínio e escreve os arquivos de pesquisa, o gsd-planner lê o contexto e escreve os arquivos de plano, e o gsd-plan-checker valida a qualidade do plano e dispara revisão até os quality gates passarem

Repara que o plano só sai da mesa quando passa num portão, não quando o modelo diz "pronto!"

E o /gsd-new-project, na largada, faz a coleta profunda de contexto por um fluxo de perguntas estruturado, opcionalmente roda pesquisa de domínio, e devolve requisitos mais um roadmap de fases

Como prevenir sem o sistema: separe a conversa de decisão da conversa de implementação

Primeiro fecha o que vai ser feito, depois abre a sessão que faz

4. A memória que mora só na conversa

Sintoma: você dá /clear, volta no dia seguinte e o agente virou outra pessoa

Todo o combinado sumiu junto com o histórico

Causa: o estado do projeto estava no chat, e chat não é banco de memória

Resposta do GSD: o GSD Core guarda todo o estado do projeto num diretório .planning/ na raiz do repositório

• PROJECT.md: descrição e requisitos
• REQUIREMENTS.md: um REQ-ID por capacidade
• ROADMAP.md: fases e status
• STATE.md: memória de sessão
• config.json: configurações do fluxo

Os arquivos de cada fase ficam dentro de .planning/phases/, com a documentação citando um exemplo bem concreto: .planning/phases/01-core-cli/01-CONTEXT.md

E o pulo do gato: tudo isso é Markdown ou JSON puro, legível por humano, gravável por agente e commitável no git

Os artefatos sobrevivem ao /clear e permitem que um subagente novo continue de onde o anterior parou

É memória compartilhada versionada, não histórico de conversa

Como prevenir sem o sistema: crie uma pasta de planejamento no seu repo e trate ela como código

Se a decisão não está commitada, ela não existe

5. O "tá pronto" sem prova nenhuma

Sintoma: o agente anuncia que terminou, você abre a aplicação e a feature não funciona

Ou funciona pela metade, que é pior, porque passa despercebido

Causa: quem escreveu o código é quem está dizendo que o código está certo

Sem evidência no meio, "pronto" é só uma frase

Resposta do GSD: o /gsd-verify-work roteia a verificação de forma determinística

O auto-pass só acontece no caso totalmente provado: human_judgment: false, lista de verification não vazia e todas as entradas com status pass

Qualquer outra coisa (human_judgment: true, verification vazia, status diferente de pass ou erro de schema) volta pra revisão humana

E tem mais: o UAT.md precisa registrar evidência antes de rodar /gsd-ship, e tanto /gsd-review quanto /gsd-ship param pra aprovação humana explícita

O default da dúvida é o humano, não o otimismo do agente

Como prevenir sem o sistema: nunca aceite "implementado" como status

Peça o que foi verificado, como foi verificado e o que ficou de fora

Quando esse nível de processo compensa (e quando é peso morto)

Agora a parte honesta, porque não existe processo de graça

Fase, plano, verificação e evidência custam tempo antes de sair a primeira linha de código

Em projeto que vai durar, isso é investimento

Em script de uma tarde, isso é cerimônia

A régua que eu uso pra decidir é simples: esse código vai ser lido de novo daqui a duas semanas?

Se vai, o processo paga

Se não vai, relaxa e segue no papo com o agente mesmo

O que muda quando o processo entra antes do código

Aqui eu falo da minha experiência com vibe coding, não com o GSD

Eu passei os últimos meses testando ferramenta gratuita e paga, de empresa grande e de empresa pequena, criando e lançando projeto real só pra ver o que acontecia

E hoje eu praticamente não programo: meu papel virou coordenar a IA pra ela construir o projeto

No vídeo eu mostro um projeto completo que eu criei sem escrever uma linha de código, com autenticação, integração de pagamento e integração com IA, rodando no ar

O ciclo é esse: descrevo o que quero, testo o resultado e vou dando novas orientações pra IA corrigir e melhorar

Agora compara os dois tempos

Hoje, com vibe coding, às vezes uma semana pra ter um projeto rodando

A plataforma que a minha equipe construiu do zero, antes de existir IA, levou 2 anos

A velocidade JÁ existe, entendeu? Ela não é mais o gargalo

O que falta é método pra essa velocidade não voltar em retrabalho

Porque o erro mais caro do vibe coding, na minha visão, é pedir do jeito errado

Dá pra criar tudo com IA, mas sem saber pedir aparecem problemas de segurança, escala e performance: sistema hackeável, gente vendo dado que não deveria ver, acesso lento

É por isso que eu insisto que quem faz vibe coding precisa entender o que roda por baixo do capô (desenvolvimento web, banco de dados, versionamento, deploy), mesmo sem digitar o código

E é exatamente esse buraco que um sistema como o GSD tenta tapar do lado do processo: decisão capturada, spec escrita, estado versionado e verificação com evidência

No vídeo acima eu mostro o projeto no ar e falo do ciclo de pedir, testar e corrigir, que é o mesmo ciclo que o GSD tenta transformar em fase com portão de qualidade

Por onde começar

O diagnóstico do post cabe em uma linha: o agente não é rápido demais, ele é impreciso cedo demais

A imprecisão entra na primeira frase vaga e só aparece três horas depois, no bug

Cada pilar do get-shit-done ataca um pedaço disso: contexto fresco contra o context rot, spec contra o prompt vago, Discuss contra a decisão não capturada, .planning/ contra a memória volátil e verificação determinística contra o "tá pronto" sem prova

Se você quiser experimentar, o caminho é curto:

1. Rode o instalador no runtime que você já usa

npx @opengsd/gsd-core@latest

O instalador pergunta o runtime e se a instalação é global ou local, então leia as perguntas antes de sair apertando enter

2. Se preferir já responder direto, passe as flags (exemplo pra Claude Code em escopo global)

npx @opengsd/gsd-core@latest --claude --global

3. Abra o projeto com o comando de entrada

/gsd-new-project

Ele faz a coleta de contexto por perguntas estruturadas, opcionalmente roda pesquisa de domínio e devolve requisitos mais roadmap de fases

4. Confira o .planning/ na raiz do repo e commite

O erro comum deste passo é tratar esses arquivos como lixo temporário: eles são a memória que sobrevive ao /clear, então vão pro git junto com o código

E o erro comum de todos os passos, esse vale repetir: não vá pro repositório antigo

O gsd-build/get-shit-done está arquivado desde 26/06/2026 e é somente leitura

O que está vivo é o open-gsd/gsd-core, e é pra lá que vão issue, PR e discussão

Me conta depois se o teu agente melhorou com processo na frente, tô curioso pra saber

até o próximo post! 😀