15 pontos por sharpscar 2026-03-18 | 3 comentários | Compartilhar no WhatsApp

Problema

Quando você começa um projeto com vibe coding, as primeiras horas parecem um mundo novo. Você joga um prompt, o código sai, parece que algo está funcionando, e chega aquele momento de pensar: "Será que eu estou mesmo construindo isso?"

E então os erros começam a aparecer.

Quando você pede para corrigir, outra parte quebra; depois de 30 minutos, a AI esquece o que disse antes; depois de 1 hora, até eu começo a me confundir sobre o que estava tentando construir. No dia seguinte, quando abro de novo, parece uma folha em branco. No fim, fico girando no mesmo lugar.

Se você toca vários projetos ao mesmo tempo, isso fica ainda pior. Para continuar na quinta-feira algo que estava fazendo na segunda, é preciso configurar o contexto todo de novo desde o começo.

Causa

O gargalo não estava no código. Estava na memória.

A AI esquece quando a sessão termina, e eu também esqueço depois de alguns dias. Mas, como ninguém registra nada, o projeto continua sendo reiniciado o tempo todo.

Método que tentei

Comecei a usar o Obsidian como armazenamento de memória de longo prazo do projeto.

  • Obsidian — gerenciamento em Markdown de planejamento, arquitetura, logs de sessão e registros de erro
  • Claude Desktop + MCP — papel de "maestro", lendo diretamente as notas do Obsidian e discutindo a arquitetura
  • Claude Code + MCP — papel de "executor", implementando de fato as tarefas cuja arquitetura já foi definida

O problema de perda de contexto no Claude Desktop foi resolvido registrando a passagem de contexto entre sessões em um arquivo data_handoff.md. Ao abrir uma nova sessão, basta ler esse arquivo para recuperar imediatamente o contexto.

O ponto central era repetir o ciclo "registrar → projetar → implementar → registrar".

Resultado

Antes, eu repetia o ciclo de começar um projeto pessoal e apagar a pasta três dias depois. Depois que mudei para esse método, os projetos que eu não conseguia concluir começaram, um a um, a entrar no ciclo de primeira versão pronta → deploy → revisão → correção. Atualmente, estou gerenciando ao mesmo tempo mais de 10 projetos em um canvas do Obsidian.

Recentemente, o Claude Code ganhou a função Auto Memory. Mas isso são anotações que a AI escreve para a própria AI; o método acima são registros que um humano escreve para outro humano. Acho que as duas coisas se complementam.

Resumo

Organizei esse workflow e publiquei como um livro no Wikidocs. O texto completo é gratuito.

"Por que o vibe coding fracassa — Guia de colaboração com AI" https://wikidocs.net/book/19307

Tem do prólogo até o Ch.22, além do apêndice, e se você deixar feedback nos comentários de cada página, vou refletir isso imediatamente. Até uma crítica mais dura é bem-vinda.

3 comentários

 
runableapp 2026-03-19

Uso o Cursor e não passei por esse tipo de situação (de ele esquecer), então às vezes estranho quando leio casos assim com o Claude. Já tive problemas por qualidade baixa ou por não especificar com precisão, mas não por ele esquecer; e situações complicadas por erro em outro lugar aconteceram algumas vezes no começo do produto Cursor, mas hoje não tive mais isso. Será que é porque meu projeto não é grande o bastante?

Faço assim:

  • Escrevo um documento de 10 a 20 linhas com a ideia geral, o método e, se houver alguma abordagem parecida, também a menciono.
  • Peço que ele leia isso e escreva um documento detalhado com a concepção, arquitetura, testes e plano, e digo para me fazer perguntas se precisar. (Aí ele costuma me perguntar escolhendo opções numeradas.) Depois discuto isso com ele até finalizar. Também converso separadamente com o Gemini para fazer mais pesquisa, e conversamos juntos sobre isso.
  • Depois reviso o documento finalizado, vou ajustando aos poucos em novas conversas e então mando construir. Enquanto implementa, peço que marque o que foi concluído e avance atualizando esse documento. E, se for algo grande ou complexo o suficiente para levar bastante tempo, peço nas regras do Cursor que registre em outro documento o que foi feito a cada dia.

Como os documentos ficam dentro do projeto, não preciso gerenciar nada de especial à parte. E o Cursor não continua trabalhando indefinidamente. Por mais que eu mande ir até o fim, ele sempre para no meio (dizem que isso é uma proteção para não cair em loops estranhos, mas me incomoda não ter escolha). Isso acaba me forçando a conversar com ele. Ainda assim, isso ajuda. Também evita que, quando eu for olhar horas depois, as coisas tenham ido parar em uma direção completamente sem sentido.

Como tudo é resolvido dentro de uma única IDE, não preciso acoplar outros serviços. Do Claude eu só usei a função de LLM pela API, então não sei como ele é para programar, embora muita gente diga que é bom — mas quando às vezes vejo posts dizendo que ele esquece coisas ou dá erros, também fico pensando se é porque o tamanho do projeto é pequeno...

No fim das contas, eu toco isso como quando se gerenciam projetos e equipes na empresa — documentação e registro, conversa, decisões, do mesmo jeito que se trabalha com pessoas. Não é um workflow novo. Por isso fico muito curioso sobre os workflows em que dizem ter feito tudo de forma "totalmente automática" com o Claude e, mesmo que não seja totalmente automático, também penso em como reduzir essas "reuniões" frequentes (assim como, em equipes formadas por pessoas, também tentamos reduzir reuniões frequentes).

 
pari0130 2026-03-19

Se você usar algo chamado qmd, ele gerencia localmente um banco de dados para controlar sessões anteriores!

 
sharpscar 2026-03-19

Obrigado pela ótima informação.