📝 Bit Flipper: como criei um jogo conversando com o Claude Code
Em poucas palavras
O que o leitor ganha? Um relato cronológico, com as mensagens reais e seus horários, de como criei o Bit Flipper, um jogo incremental sobre bits e computação, em três dias de conversa com o Claude Code. Mostro como a nossa relação foi mudando: das correções de detalhe à delegação de processos inteiros, sem abrir mão das decisões que importam.
Público-alvo: Professores, estudantes e desenvolvedores curiosos sobre como é, na prática, criar software dirigindo um agente de IA.
O jogo: Caso queira conferir o game, ele está público nesta página em Bit Flipper by RafaelAlvesITM
📝 Introdução
Num sábado à tarde, 10 de outubro de 2026, abri o Claude Code com uma ideia simples: um jogo incremental, no estilo de Cookie Clicker e Magic Archery, em que o jogador começa invertendo um único bit apertando um botão e, aos poucos, vai construindo um computador inteiro. Cinco dias depois, o jogo tinha duas versões lançadas, uma build pronta para testes no itch.io, um instalador para Windows e a capa que você vê abaixo.
Este post não é sobre o jogo em si, mas sobre como eu fui conversando com a ferramenta ao longo desses dias. Olhando o histórico completo da conversa, com a data e a hora de cada mensagem, fica claro que a nossa forma de trabalhar mudou bastante: no começo eu corrigia cada detalhe a cada cinco minutos, e no fim eu pedia processos inteiros em uma única frase. É essa mudança que quero mostrar.
Para quem está chegando agora: o Bit Flipper é um jogo de clique em que o registrador da CPU começa com 1 bit e cresce até 64. Quando ele transborda (overflow), o “vai um” cai na memória, que é o dinheiro do jogo. Com ela, você compra chips (do transistor ao chip quântico), melhorias numa árvore de buffs e, de vez em quando, corrige bits invertidos por raios cósmicos. É, assumidamente, um projeto de Vibe Coding: eu fui o diretor, e o Claude Code escreveu o código. Caso queira conferir o game, ele está público nesta página em Bit Flipper by RafaelAlvesITM
📖 Desenvolvimento
A linha do tempo
As minhas 39 mensagens se concentraram em três janelas: sábado, das 13h44 às 17h23; segunda-feira, das 11h50 às 15h32; e quinta-feira de manhã, das 7h às 8h32.
timeline title Bit Flipper em três dias de conversa section Sábado, 10 de outubro 13h44 : A ideia e o plano : TypeScript e Electron, de olho na Steam 13h51 às 14h53 : Marcos 1 a 5 : ajustes finos de mecânica e de interface 15h00 às 15h57 : O que mais? : layout de Cookie Clicker, 64 bits, reboot e app de desktop 16h18 : Git, simulador de balanceamento e documento de design 17h23 : Efeitos visuais section Segunda, 12 de outubro 11h51 : Reavaliação e primeira build 12h18 : Música adaptativa e versão 0.3.0 13h01 : A virada para jogo sério 14h38 : Corrupção silenciosa 15h32 : Projetos de chips e pistas por era section Quinta, 15 de outubro 07h00 : Versão 0.4.0 pronta 07h52 : Pacotes para o itch.io 08h06 : Capa e página do jogo 08h32 : Este post
Sábado, 13h44: o plano antes do código
A primeira mensagem já terminava com um pedido que acabou virando padrão: antes de escrever código, me ajude a criar um plano. O Claude Code propôs uma divisão em marcos (milestones), e a minha segunda mensagem não foi sobre o jogo, mas sobre o destino dele: eu queria publicar na Steam por algo como R 2,99, e perguntei se usar TypeScript não seria uma má ideia. Discutimos as alternativas, e eu decidi ficar com TypeScript e Electron. Logo em seguida, às 13h51, veio o “sim, comece pelo marco 1”.
Sábado, das 13h51 às 14h53: eu dirigia cada detalhe
Entre 13h44 e 14h53, mandei 14 mensagens, uma a cada cinco minutos, em média. O ciclo era sempre o mesmo: o Claude Code implementava, eu jogava, e eu corrigia. Alguns exemplos:
- Na quinta mensagem, o professor apareceu: eu queria ensinar visualmente o que acontece na conversão de bits para números, e escolhi a opção de mostrar a memória e o processamento dentro de um computador (o caminho CPU → RAM que está no topo da tela até hoje).
- Pedi que o clique viesse antes de tudo, que as melhorias valessem mais do que simplesmente aumentar o registrador e que houvesse um botão para guardar o valor na memória antes do overflow.
- Cinco minutos depois, mudei de ideia sobre o meu próprio pedido: guardar e transbordar deveriam render o mesmo, e o registrador deveria zerar ao guardar.
- Defini que aumentar a largura do registrador seria a primeira melhoria do jogo, com um bônus para quem esperasse o overflow.
- Na interface: estatísticas num submenu, botões centralizados, números com K, M e B, como nos jogos incrementais, e o registrador em linhas de 4 bits, com os bits ainda bloqueados em cinza.
O começo do jogo, já na versão 0.4.0: o registrador em linhas de 4 bits e um raio cósmico atingindo um bit.
Sábado, das 15h00 às 17h23: de “faça isso” para “o que mais?”
Às 15h00, a natureza das mensagens mudou. Em vez de dizer o que fazer, perguntei: “o que mais eu deveria adicionar a este jogo?”, já sugerindo um painel de chips e outro de buffs. Três minutos depois, respondi às sugestões com um “sim, melhore o jogo com as suas sugestões, acho que estamos indo numa boa direção”.
A partir daí, eu dava a direção e a referência, e deixava a execução com a ferramenta:
- Pedi o layout do Cookie Clicker, em três colunas, com os buffs apresentados como um grafo de melhorias conectadas, como em outros jogos incrementais.
- Pedi para continuar melhorando e adicionando coisas, e cortei o botão de guardar na memória, que eu tinha pedido cerca de uma hora e meia antes, porque percebi jogando que não o usava.
- Pedi a geração de 64 bits (o registrador RAX) e um sistema de reboot com melhorias de firmware, e empacotei o jogo como aplicativo de desktop com o Electron.
A árvore de buffs no estilo de grafo que pedi no sábado, aqui na era SVGA.
Às 16h18 veio o pedido mais aberto do dia: iniciar um repositório Git e revisar os números, o layout, a história e o design do jogo usando as melhores escolhas de game design e teoria dos jogos, com uma análise completa. Para balancear os números, o Claude Code escreveu um simulador que joga o jogo sozinho e mede quanto tempo leva cada etapa. A análise veio num documento de design, e eu respondi às perguntas dele com comentários no próprio documento. Sobre a duração estimada, de cerca de 31 horas até o final, respondi que estava bom para um jogo de Vibe Coding que é, em tradução livre, “meio que uma colagem de ideias de outros jogos”.
A história, com o registro do sistema (o SYSTEM LOG) e um sinal de 248 bits trazido pelos raios cósmicos, foi proposta pela ferramenta nessa revisão. Na última mensagem do sábado, pedi efeitos visuais porque achava o jogo sem graça e pouco memorável, “mesmo que a história que você criou seja interessante”.
Segunda, das 11h50 às 12h26: avaliar, polir e lançar
Na segunda-feira, pedi para reavaliar o jogo e criar uma primeira build para teste. Os efeitos do sábado tinham virado as eras de tela: o jogo começa num terminal de fósforo verde e evolui para monitor âmbar, CGA, SVGA e cor verdadeira à medida que o registrador cresce. Joguei, e escrevi que o jogo estava bom, com uma progressão decente e “meio viciante”. Pedi então uma música de fundo, ligada por padrão, mas que pudesse ser desligada. O resultado foi uma trilha chiptune sintetizada em código, sem nenhum arquivo de áudio, que ganha camadas a cada era de tela. Às 12h26, pedi o commit e o lançamento: a versão 0.3.0.
Segunda, das 13h01 às 15h32: a virada para jogo sério
Às 13h01, escrevi que achava o jogo incrível do jeito que estava, e pedi ideias para transformá-lo num jogo sério, usando o melhor conhecimento da comunidade científica. A resposta trouxe um panorama da literatura e um conjunto de ideias agrupadas por princípio. Oito minutos depois, tomei a decisão que definiu o resto do projeto: ficar só com a primeira referência, a integração intrínseca de Habgood e Ainsworth (2011), na qual o conteúdo se aprende jogando a própria mecânica, e não respondendo a um quiz que paga recompensa. É a diferença entre um jogo sério de verdade e a simples Gamificação.
A ideia de como fazer isso foi minha: manter o jogo simples, mas com uma camada a mais para quem quiser. O jogador poderia resolver problemas ao clicar nos raios cósmicos e, para cada chip, resolver um problema ligado à função daquele chip para melhorar a sua eficiência. E, de novo, pedi primeiro um plano.
O plano veio com três perguntas, e eu respondi as três numa única mensagem: errar não teria punição além do próprio bit trocado; as melhorias seriam permanentes durante a partida, mas zeradas no reboot, como os outros buffs (copiei a recomendação da própria ferramenta); e o trabalho começaria só pelo primeiro passo, para eu jogar antes de continuar.
Foi nesse passo que aconteceu uma das coisas mais interessantes da conversa: o Claude Code discordou do plano que ele mesmo tinha proposto, com números. O simulador mostrou que a recompensa planejada praticamente cortava pela metade o tempo até o final para quem resolvesse tudo e ainda atrasava quem ignorasse os desafios. Ele propôs outra forma, eu aceitei, e pedi para juntar a versão na branch principal e seguir para os passos seguintes.
Ao fim da segunda-feira, o jogo tinha:
- Corrupção silenciosa: alguns raios cósmicos invertem um bit sem mostrar qual. O jogador precisa encontrá-lo a partir de uma pista que muda com cada era de tela: um valor em decimal, depois em hexadecimal, depois um caractere ASCII, depois bits de paridade e, por fim, as checagens de um código de Hamming de verdade.
- Projetos de chips: cada um dos 10 chips ganhou três quebra-cabeças sobre o que aquele chip faz, num total de 30: circuitos de chaves, tabelas-verdade e portas NAND, soma binária com “vai um”, máscaras de bits, complemento de dois, ordem de instruções, balanceamento de carga, SIMD, roteamento em hipercubo e qubits.
- Verificação automática: um script que gera 9.000 quebra-cabeças e testa 21.800 casos de corrupção, garantindo que todos têm solução e que cada pista aponta para exatamente um bit.
Um projeto de chip: montar uma função usando só portas NAND, com a tabela-verdade sendo conferida ao vivo.
Corrupção silenciosa na era CGA: o byte deveria guardar a letra “M” em ASCII, mas guarda 0x0D.
O registrador completo de 64 bits: as células numeradas e as checagens de Hamming apontam qual bit foi invertido.
Quinta, das 7h00 às 8h32: delegando processos inteiros
Na quinta-feira, mandei só quatro mensagens, e cada uma pedia um processo completo, não uma funcionalidade:
- “Faça os passos necessários para o jogo ficar pronto para a versão 0.4.0.” O Claude Code rebalanceou o jogo com um jogador simulado que resolve 80% dos desafios (cerca de 25 horas até o final, contra cerca de 37 horas para quem os ignora), colocou a versão do jogo na tela, escreveu as notas de versão e gerou e testou o instalador.
- “Prepare uma versão para eu publicar no itch.io e testar.” Ele empacotou a versão web e a de Windows, testou o jogo dentro de um iframe, como o itch.io o exibe, e, nesse teste, encontrou e corrigiu um erro que aparecia quando o jogo era embutido numa página.
- “Crie uma imagem de capa e os detalhes do jogo para o site do itch.io.” A capa foi montada com a própria arte do jogo, as capturas de tela foram geradas por um script que monta cenas reais do jogo, e o texto da página veio com todos os campos do formulário.
- Este post.
O que mudou na nossa relação
| Fase | Quando | Como eu pedia | O que o Claude Code fazia |
|---|---|---|---|
| Plano | Sábado, 13h44 | ”Me ajude a criar um plano” | Propunha marcos e opções |
| Detalhe | Sábado, 13h51 às 14h53 | Correções pontuais a cada 5 minutos | Implementava exatamente o pedido |
| Direção | Sábado, 15h00 às 17h23 | ”O que mais?”, “use as melhores escolhas de game design” | Propunha sistemas, história e números, e media com um simulador |
| Avaliação | Segunda, 11h50 às 12h26 | ”Reavalie”, “crie uma build” | Revisava, testava e empacotava |
| Propósito | Segunda, 13h01 às 15h32 | Uma referência científica e três decisões minhas | Planejava, implementava e discordava com dados |
| Processo | Quinta, 7h00 às 8h32 | Um objetivo inteiro por mensagem | Executava o processo de ponta a ponta e relatava os desvios |
O que ficou comigo durante todo o caminho: a ideia e o tema, as referências de estilo, a escolha da plataforma, o julgamento do que era divertido (que só vinha jogando), os cortes, a direção de jogo sério, a escolha da referência científica, as decisões de design e o momento de cada commit e de cada lançamento. O que eu deleguei: a implementação, o balanceamento numérico, a história, a música, a arte em pixel (desenhada por código), os testes, o empacotamento e a capa.
Alguns combinados também surgiram no caminho, sem que eu precisasse escrevê-los numa lista:
- Plano antes de código nas mudanças grandes, tanto no início quanto na virada para jogo sério.
- Commit e lançamento só quando eu pedia. No sábado e na segunda, todo commit veio de um pedido explícito meu. Na quinta, quando passei a pedir processos inteiros, os commits passaram a fazer parte do próprio processo.
- Testes destrutivos numa cópia separada do jogo. No começo, um teste apagou o meu save, que foi recuperado de um backup. Desde então, os testes rodaram numa cópia à parte.
- Decisões em forma de pergunta. Quando havia escolhas de design, elas vinham com opções e uma recomendação, e a decisão era minha.
Os números da conversa
| Item | Valor |
|---|---|
| Dias de conversa | 3 (10, 12 e 15 de outubro de 2026) |
| Mensagens minhas | 39 (incluindo 2 comentários no documento de design) |
| Commits | 9 |
| Versões lançadas | 2 (0.3.0 e 0.4.0) |
| Linhas de código | cerca de 7.500 (TypeScript, CSS, HTML e scripts) |
| Chips | 10, do transistor ao chip quântico |
| Quebra-cabeças de projeto de chip | 30 |
| Eras de tela | 5 |
| Conquistas | 39 |
| Tempo estimado até o final | cerca de 37 horas ignorando os desafios, cerca de 25 horas resolvendo |
Para fechar
O jogo nasceu de uma ideia minha e foi escrito pela ferramenta, mas o histórico mostra que o trabalho não foi uma linha reta de pedidos. Ele começou com correções minuciosas e terminou com a delegação de processos inteiros, e essa confiança cresceu à medida que o Claude Code mostrou o próprio trabalho: um simulador para justificar os números, testes para provar que os quebra-cabeças tinham solução e a disposição de contrariar o próprio plano quando os dados pediam. Ao longo de todo o caminho, porém, as perguntas sobre o que o jogo deveria ser continuaram sendo minhas.
Como este texto foi escrito
O rascunho deste post foi gerado pelo Claude Code, a meu pedido, a partir do histórico da própria conversa, com a data e a hora de cada mensagem, e do histórico do Git do projeto.
E você?
Se você fosse criar um projeto inteiro conversando com um agente de IA, em que momento passaria a delegar processos inteiros, e quais decisões faria questão de manter só suas?
📚 Referências e Fontes
🔗 Conexões do Cofre
- Conceitos:
- Posts irmãos: