Retrospective: Um mês de Vibe Coding insano com Claude para armazenamento local no jogo

Nesse último mês no trampo, eu mergulhei de cabeça no vibe coding com o Claude (geralmente uso o Gemini pras minhas paradas). A empresa liberou uma cota de API absurda, e eu fiquei encarregado de criar uma nova feature de galeria de fotos local pro nosso jogo. Então, inverti o jogo: eu faria o papel de arquiteto lidando com a visão geral, e deixaria o Claude Opus 4.6 ser o peão de obra (code monkey).

Depois de um mês inteiro nisso, mando a real: quando você sabe exatamente o que quer, a IA é um monstro. Mas no segundo que você começa a mudar requisitos ou tentar matar bugs, a experiência humana ainda é 100% insubstituível.

Quando você sabe o que quer, ela destrói

Na fase de setup inicial, contanto que eu desse limites bem rígidos, o Claude cuspia exatamente o que eu precisava.

Por exemplo, pra evitar que os arquivos locais corrompessem, pedi uma trava de segurança de dados. O Claude pegou a ideia na hora e meteu um pattern WAL (Write-Ahead Logging) perfeito direto do SQLite. Ele cravou a lógica pros arquivos temporários, trocas atômicas e crash recovery. Nesse ponto, se a sua especificação for clara, a IA faz o trabalho sujo perfeitamente e te salva um tempão escrevendo código inútil (boilerplate).

Choque de realidade: a visão de túnel da IA com bugs

Mas a lua de mel acabou no segundo que começamos a mexer nas features e arrumar bugs. Foi aí que os limites do Claude gritaram.

O maior ponto cego da IA é que ela tem zero noção do projeto inteiro. Quando a lógica bate de frente, a reação dela é logo fazer uma gambiarra (botar um band-aid). Ela adora socar uma flag booleana do nada ou entupir de if-else em vez de dar um passo pra trás e encaixar o fix direito no sistema. Se você for na onda da IA cegamente aqui, seu código vai virar um pesadelo pra dar manutenção rapidinho.

Uma cagada clássica: Reference Counting de Cache de Texture2D

Eu caí num exemplo clássico disso montando um sistema de reference counting de cache de Texture2D em C#.

A ideia toda era gerenciar a memória das páginas da galeria. Eu dividi o cache em duas zonas: ativa e inativa. Se uma textura tem referência, fica ativa; se zerar, é jogada pro buraco das inativas, pronta pra ir pro lixo.

O negócio desandou quando misturei callbacks assíncronos com as referências. O Claude fez uma lógica de timing totalmente bizarra: ele jogava a página pras inativas antes de marcar a referência. Isso gerou uma race condition cabulosa. Se o cache já tivesse cheio, jogar pras inativas ia engatilhar a limpeza na mesma hora, trucidando a página antes do callback assíncrono sequer ter a chance de marcar a referência.

A grande ideia do Claude pra arrumar isso? Colocar uma flag super gambiarra chamada is_early_marked pra simplesmente ignorar o problema de ciclo de vida.

Eu cortei o barato na hora. Sabendo como o ciclo de vida do componente funciona de verdade, dei uma regra clara: atrasa a limpeza da página inativa até depois que a operação assíncrona marcar a referência. Arrumando o timing direto na arquitetura, o bug foi obliterado — sem precisar de flag suja.

Resumo da ópera

Isso tudo provou que, embora a IA te faça programar mil vezes mais rápido, ela esconde débito técnico muito fácil.

Se um dev júnior esbarrasse nesse bug assíncrono, provavelmente ele só daria merge na gambiarra do Claude. Passa umas semanas e você tem um monte de flags e lógicas inúteis, e o módulo já não tem salvação. Com o vibe coding, você não precisa escrever cada linha, mas ficar de olho no cenário geral e impedir a criação de um código espaguete é um trampo que só humanos conseguem fazer.