DEV Community: André N. Darcie

Diferença entre vibe coding com IA e engenharia com IA

André N. Darcie — Tue, 28 Jul 2026 19:19:44 +0000

As duas abordagens são válidas e úteis no desenvolvimento de software.
Um desenvolvedor que utiliza apenas uma delas pode estar deixando de aproveitar parte do potencial da inteligência artificial.

Vibe coding com IA

O desenvolvedor utiliza a IA para gerar o código, mas não revisa detalhadamente a implementação.
Ele solicita uma funcionalidade, verifica se ela funciona e realiza alguns testes.
A revisão do código costuma ser superficial.
Normalmente, o desenvolvedor apenas observa se existem problemas evidentes, como:
- arquivos excessivamente grandes;
- estruturas muito complexas;
- código claramente exagerado;
- funcionalidades que não funcionam como esperado.
É possível criar aplicações complexas dessa forma, com muitas funcionalidades e boa utilidade prática.
Porém, essa abordagem geralmente não é adequada para sistemas críticos.
O software pode:
- automatizar processos;
- resolver problemas do dia a dia;
- atender muitos usuários;
- gerar receita;
- validar uma ideia de negócio.
Os possíveis erros precisam ter consequências pequenas e administráveis.
Quando algo dá errado, normalmente é apenas um bug que pode ser corrigido sem causar grandes prejuízos.
É uma abordagem excelente para:
- protótipos;
- MVPs;
- aplicações internas;
- experimentos;
- projetos pessoais;
- produtos rápidos;
- validação de ideias com clientes.
O principal objetivo é colocar a solução nas mãos dos usuários rapidamente.
Assim, é possível descobrir se existe demanda ou potencial de faturamento antes de investir muito tempo e dinheiro.
Em muitos casos, fazer engenharia excessiva ou otimização prematura pode ser um erro maior do que lançar uma solução simples.

Engenharia de software com IA

A IA também pode gerar código, testes, documentação e sugestões de implementação.
A diferença é que o resultado precisa ser cuidadosamente analisado.
O desenvolvedor precisa compreender e revisar o código produzido.
As regras de negócio devem ser verificadas de forma rigorosa.
Decisões técnicas importantes não devem ser simplesmente delegadas ao modelo.
Em sistemas críticos, a linguagem natural não pode ser a única forma de especificação, pois é ambígua.
Um único if incorreto pode provocar:
- prejuízos de milhões de reais;
- clientes frustrados;
- incidentes operacionais;
- falhas de segurança;
- problemas jurídicos;
- reclamações em órgãos reguladores, como o Banco Central.
Não basta apenas o autor do código revisar a implementação.
A validação precisa envolver toda a equipe.
O processo pode incluir:
- testes automatizados;
- testes de integração;
- validações das regras de negócio;
- critérios de segurança;
- observabilidade;
- análise de desempenho;
- revisão coletiva durante o code review.
A IA acelera o desenvolvimento, mas não elimina a responsabilidade humana.

Principal diferença

No vibe coding, o foco está principalmente no resultado, na velocidade e na validação da ideia.
Na engenharia com IA, o foco está também na confiabilidade, na segurança, na manutenção e na redução de riscos.
No vibe coding, o desenvolvedor verifica principalmente se o sistema funciona.
Na engenharia com IA, a equipe precisa entender por que ele funciona e garantir que continuará funcionando corretamente.
A diferença não está apenas em usar ou não inteligência artificial.
A diferença está no nível de compreensão, revisão e responsabilidade assumido sobre o código gerado.
A IA pode acelerar as duas abordagens, mas, em sistemas críticos, a responsabilidade final continua sendo humana e compartilhada por toda a equipe.

Os hobbies mais valem a pena, segundo a ciência

André N. Darcie — Wed, 22 Jul 2026 20:26:24 +0000

Quem programa passa o dia sentado, sozinho e com a cabeça em telas, o que torna a escolha do hobby uma decisão de arquitetura de vida, não um detalhe. Então fui atrás da literatura: coortes prospectivas grandes, meta-análises e ensaios randomizados, cruzando sete dimensões (mortalidade, cardiometabólico, cognição, saúde mental, vida social, carreira e acessibilidade). A conclusão mais desconfortável logo de cara: academia sozinho, que é o default de quase todo mundo, rende muito menos do que parece. No Copenhagen City Heart Study, com 8.577 pessoas seguidas por até 25 anos, atividades de academia se associaram a 1,5 ano a mais de expectativa de vida, contra 9,7 anos do tênis [1].

O melhor desempenho puramente físico é o dos esportes de raquete, e isso não é achado de um estudo só. Em Copenhague, tênis (9,7 anos) e badminton (6,2 anos) lideraram com folga sobre ciclismo (3,7), natação (3,4) e corrida (3,2) [1]. Numa coorte britânica independente, com 80.306 adultos, esportes de raquete tiveram o menor risco de morte por qualquer causa (HR 0,53; IC95% 0,40 a 0,69) e por causa cardiovascular (HR 0,44; 0,24 a 0,83), à frente de natação (0,72) e ginástica aeróbica (0,73). Corrida e futebol, nessa mesma coorte, não atingiram significância estatística [2]. Dois países, duas amostras, mesmo pódio.

A alternativa barata para quem não vai virar sócio de clube de tênis é dançar. Numa análise agrupada de 11 pesquisas populacionais britânicas (48.390 adultos, 1.714 mortes cardiovasculares), dança de intensidade moderada rendeu HR 0,54, batendo a caminhada moderada, que ficou em 0,67 [3]. E no Bronx Aging Study, publicado no NEJM, a dança foi a única atividade física associada a menor risco de demência; o escore geral de atividade física ficou em HR 1,00, ou seja, zero [4]. Isso é observacional, mas há reforço randomizado: meta-análise de 11 ensaios (1.412 participantes) achou ganho de cognição global com dança (diferença média de 1,58 ponto no MMSE) e de memória (3,02 no teste de Wechsler) [5]. Detalhe que muda tudo: dança de intensidade leve não mostrou efeito algum. Precisa suar.

O item mais subestimado da lista é voluntariado regular, e ele tem o melhor desenho causal entre os estudos observacionais que levantei. Um estudo censitário da Irlanda do Norte acompanhou 308.733 casais: voluntários tiveram HR 0,78 (homens) e 0,77 (mulheres) de mortalidade, enquanto os cônjuges não-voluntários dessas mesmas pessoas ficaram em HR 1,01 e 1,00 [6]. Como renda, escolaridade e ambiente são compartilhados dentro de casa, isso derruba boa parte da explicação "é só efeito socioeconômico". Duas meta-análises independentes chegam ao mesmo lugar por outro caminho: RR 0,78 agrupando cinco coortes [7] e 24% de redução após ajuste para mediadores, em 14 estudos [8]. Três fontes, três desenhos, o mesmo número. E o suposto buraco cardiometabólico do voluntariado não existe: no Health and Retirement Study, quem fez ao menos 200 horas de voluntariado no ano anterior teve OR 0,60 de desenvolver hipertensão em 4 anos, sem nenhum efeito protetor em doses menores [9]. No lado cognitivo, o Baltimore Experience Corps Trial randomizou 702 idosos para mentoria em escolas e mediu ganho de função executiva e preservação de volume cortical e hipocampal [10].

O retorno de carreira também existe, mas é aqui que o número mais citado engana. Num experimento com 579 gestores de RH alemães avaliando currículos idênticos, sinalizar voluntariado social aumentou a chance de entrevista em 37 pontos percentuais, efeito equivalente a subir dois níveis de nota escolar. Só que esse resultado é da amostra de candidatos a vaga de aprendizagem, jovens de 17 anos. Na amostra de universitários recém-formados — ou seja, provavelmente você — voluntariado não teve efeito estatisticamente significativo (coeficiente 0,07). O que funcionou nesse grupo foi outra coisa: praticar esporte coletivo em vez de individual, +10 p.p. Os autores levantam a hipótese de que, aos 24 anos, o RH já desconfia que voluntariado é sinal fácil de manipular, enquanto o tipo de esporte que alguém escolhe continuar praticando não é [11]. Esporte coletivo, aliás, também ganha de esporte individual em saúde mental: revisão sistemática de 29 estudos com adultos de 18 a 84 anos encontrou desfechos mais favoráveis em quem joga em time, atribuídos ao suporte social do clube [12].

Duas opções que custam literalmente zero se saíram melhor do que eu esperava. Caminhada em grupo tem a meta-análise de intervenção mais completa da lista: 42 estudos, quedas de 3,72 mmHg na pressão sistólica, 3,14 na diastólica, melhora de VO2máx e efeito sobre depressão de SMD −0,67, sem nenhum efeito adverso relatado [13]. E participação em comunidade religiosa produz um dos maiores números de longevidade que encontrei: no Nurses' Health Study, com 74.534 mulheres, frequentar culto mais de uma vez por semana se associou a HR 0,67 de mortalidade por qualquer causa contra quem nunca frequentava, com mortalidade cardiovascular e por câncer também menores [14]. Guarde a ressalva, porque ela é grande: quem frequenta é sistematicamente diferente de quem não frequenta, e nenhum ajuste estatístico resolve isso por completo.

Por que "social" aparece em quase todo lugar deste texto? Porque é um fator de risco de mortalidade por si só. A meta-análise clássica de Holt-Lunstad, com 148 estudos, encontrou OR 1,50 de sobrevivência a favor de quem tem relações sociais fortes, magnitude comparável à de parar de fumar e maior que a de hipertensão e obesidade [15]. Uma segunda meta-análise dos mesmos autores separou os componentes: isolamento social OR 1,29, solidão 1,26, morar sozinho 1,32 [16]. Um hobby que coloca outra pessoa na sala não está ganhando um bônus simpático, está mexendo em algo do tamanho do cigarro.

Se o seu problema é tempo, a boa notícia é que a dose eficaz é ridiculamente pequena. Meta-análise de 16 coortes prospectivas mostra curva em J para musculação: o menor risco aparece em 40 minutos por semana (RR 0,83), e passando de cerca de 140 min/semana o benefício de mortalidade some [17]. Para corrida, uma meta-análise com 232.149 participantes e 25.951 óbitos encontrou HR 0,73, sem nenhuma tendência dose-resposta significativa. Traduzindo: correr uma vez por semana já captura quase todo o efeito; correr mais não comprou mais anos [18]. Combinar força com aeróbico rende mais do que qualquer um dos dois isolados, RR 0,60 [17] — grande, mas nem o maior desta lista, já que raquete (0,53) e dança (0,54) ficam abaixo disso. Vale para humor também: metade da dose recomendada de atividade física (4,4 mMET-h/semana) já se associa a 18% menos risco de depressão, numa meta-análise de 15 estudos e 191.130 pessoas, com a curva mais íngreme justamente na saída do sedentarismo [19].

Jardinagem e atividades ao ar livre eu havia subestimado. Numa coorte sueca de 4.232 pessoas de 60 anos seguidas por 12,5 anos, alto nível de atividade física não-exercício — jardinagem, consertos em casa, manutenção do carro — se associou a HR 0,70 de mortalidade por qualquer causa e 0,73 de primeiro evento cardiovascular, independentemente de a pessoa se exercitar formalmente ou não [20]. Some a isso a meta-análise de 9 coortes e 8,3 milhões de pessoas ligando verde no entorno a menor mortalidade [21], e a meta-análise randomizada de atividades na natureza com SMD −0,64 para humor depressivo e +0,95 para afeto positivo [22].

Por que quase ninguém tira nota alta no eixo cérebro

Numa versão anterior desta análise eu dei zero em cérebro para corrida, natação, ciclismo, musculação, caminhada e esportes coletivos. Isso estava errado, e a razão de estar errado é a parte mais interessante da revisão.

Existe evidência randomizada de que exercício melhora cognição. Meta-análise de 39 ensaios randomizados com adultos acima de 50 anos concluiu que exercício melhora função cognitiva, tanto aeróbico quanto de força [23]. E há um ensaio célebre em que caminhar três vezes por semana aumentou em 2% o volume do hipocampo de 120 idosos, revertendo um a dois anos de perda por idade — com o ganho de memória espacial aparecendo só no grupo que caminhou, e não no grupo de alongamento [24].

Só que em 2023 uma revisão guarda-chuva juntou 24 meta-análises, 109 ensaios randomizados e 11.266 participantes saudáveis e mostrou algo incômodo: o efeito encolhe bastante quando se corrige por controle ativo e diferenças de linha de base, e vira desprezível depois de corrigir viés de publicação [25]. O achado é contestado — há réplica publicada na mesma revista —, mas é o exame mais rigoroso disponível.

Então zero estava errado, e nota alta também estaria. Neste ranking, exercício genérico leva 2 em cérebro: alguém mediu e achou alguma coisa, só que a evidência não sobrevive inteira ao escrutínio. Caminhada leva 3, porque tem o ensaio dedicado dela. Dança leva 3, e não 4 como eu havia dado, porque a meta-análise dela é boa mas está sujeita exatamente à mesma crítica. E ninguém chega a 5, porque a outra metade deste eixo é prevenção de demência, e aí o Whitehall II acompanhou 8.280 pessoas por 18 anos e não achou associação entre lazer na meia-idade e demência (HR 0,92; 0,79 a 1,06) [26].

Agora a parte que ninguém quer ouvir. Primeiro, boa parte da proteção contra demência que aparece em estudos observacionais vem de medir o lazer perto do diagnóstico, o que é causalidade reversa: parar de ter hobbies é sintoma precoce da doença, não causa [26]. Em defesa do outro lado, o estudo do NEJM excluiu quem tinha demência pré-clínica no início e a associação sobreviveu [4] — a questão está longe de resolvida. Segundo, xadrez e brain training não te deixam mais inteligente: contra grupo de controle ativo, o efeito do xadrez cai para 0,10 desvio-padrão e o de instrução musical para 0,03, com intervalo cruzando o zero [27], e a revisão de 186 páginas que auditou os estudos citados pelas próprias empresas de treino cerebral achou muita evidência de melhora na tarefa treinada e quase nenhuma de transferência ampla [28]. Terceiro, e o mais incômodo para a tese deste post: o Synapse Project randomizou idosos para aprender fotografia digital ou patchwork, 15 horas por semana, e achou ganho de memória episódica — mas o grupo de controle que apenas socializava não melhorou [29]. Companhia compra longevidade e humor; não compra cérebro. Quarto: quase tudo aqui é observacional. Quando o exercício foi testado num ensaio randomizado de 5 anos com 1.567 idosos, o treino supervisionado não reduziu mortalidade contra o grupo controle [30]. Leia os números como uma ordenação relativa plausível, não como uma promessa de anos de vida.

Como o ranking foi montado

Cada hobby recebeu uma nota de 0 a 5 em sete eixos, todos com o mesmo peso, e o placar é a soma simples, de 0 a 35. Isso premia força de evidência e amplitude ao mesmo tempo: um hobby espetacular em duas dimensões e zerado em cinco perde para um que é bom em seis.

Eixo	O que mede
Longevidade	mortalidade por todas as causas
Cardiometabólico	mortalidade cardiovascular, pressão, lipídios, glicemia
Cérebro	cognição e risco de demência
Mental	depressão, ansiedade, humor, propósito
Social	conexão e redução de solidão
Carreira	empregabilidade e habilidades transferíveis
Acessibilidade	custo e barreira de entrada

A escala: 5 = evidência forte e direta convergindo de fontes independentes; 4 = evidência forte e direta de uma fonte de alta qualidade (meta-análise, coorte grande ou ensaio randomizado); 3 = evidência direta com ressalva importante (estudo único, população restrita, exposição composta); 2 = evidência indireta, mas medida; 1 = sinal mínimo; 0 = nada a pontuar, seja porque ninguém mediu, seja porque mediram e não acharam efeito. Zero nunca significa "faz mal", e eu não vou inventar ponto onde não há estudo.

Empates são resolvidos nesta ordem: menor número de eixos zerados, depois maior quantidade de notas 5, depois nota no eixo Social. Quando nem isso separa, o empate fica declarado.

O top 10, por equilíbrio

1. Voluntariado regular: 27/35
Longevidade 5, Cardiometabólico 3, Cérebro 4, Mental 3, Social 5, Carreira 2, Acessibilidade 5.
Um dos dois únicos hobbies da lista que não zeram nenhum eixo — o outro é esporte coletivo, e não por acaso os dois são o mesmo tipo de coisa: gente reunida, com frequência, por anos. Três fontes independentes convergem em ~0,78 de mortalidade, uma delas com o teste do cônjuge descartando confundimento familiar; OR 0,60 de hipertensão a partir de 200h/ano; e o maior ensaio randomizado com desfecho cognitivo e cerebral da lista inteira — que, por não ser um ensaio de exercício, escapa da crítica da revisão guarda-chuva e por isso leva 4 em cérebro. Carreira fica em 2 porque os +37 p.p. valem para candidatos a vaga de aprendizagem, não para quem já se formou. Mental fica em 3 porque as coortes mostram efeito em depressão e bem-estar que os ensaios randomizados não confirmaram. [6][7][8][9][10][11]

2. Caminhada em grupo: 26/35
Longevidade 3, Cardiometabólico 5, Cérebro 3, Mental 5, Social 5, Carreira 0, Acessibilidade 5.
A maior surpresa da revisão, e o hobby de menor barreira de entrada que existe: custo zero, equipamento zero, em qualquer lugar. Meta-análise de 42 estudos com queda de pressão, colesterol e gordura corporal e ganho de VO2máx, mais SMD −0,67 em depressão e nenhum evento adverso. E é o único hobby aeróbico com ensaio randomizado dedicado no eixo cérebro, o do hipocampo. Buraco único: carreira. [3][13][24]

3. Esportes coletivos (futebol, vôlei, basquete): 25/35
Longevidade 3, Cardiometabólico 3, Cérebro 2, Mental 4, Social 5, Carreira 3, Acessibilidade 5.
Perfil parecido com o da raquete a um custo muito menor, e o único hobby físico com bônus de currículo comprovado justamente para quem está saindo da faculdade: 4,7 anos de expectativa de vida em Copenhague, +10 p.p. de chance de entrevista entre recém-formados e vantagem de saúde mental sobre esporte individual em 29 estudos. Longevidade leva 3 porque futebol não atingiu significância na coorte britânica. É, junto com o voluntariado, um dos dois únicos hobbies que não zeram nenhum eixo. [1][11][12]

4. Dança de par ou grupo: 23/35
Longevidade 3, Cardiometabólico 4, Cérebro 3, Mental 3, Social 5, Carreira 0, Acessibilidade 5.
HR 0,54 cardiovascular, batendo a caminhada moderada, e a única atividade física associada a menor risco de demência no NEJM, num estudo em que o escore geral de atividade física deu HR 1,00. Perdeu o 2º lugar na revisão do eixo cérebro: a meta-análise randomizada de dança é boa, mas está sujeita à mesma crítica de viés de publicação que o resto da literatura de exercício e cognição. Buraco: carreira. [3][4][5]

5. Esportes de raquete (tênis, padel, badminton, tênis de mesa): 22/35
Longevidade 5, Cardiometabólico 5, Cérebro 2, Mental 3, Social 5, Carreira 0, Acessibilidade 2.
Tem as duas notas de corpo mais altas do ranking inteiro, sustentadas por duas coortes de países diferentes, e mesmo assim fica em 5º: é o hobby mais caro da lista e não pontua em carreira. No experimento de currículos, esporte individual — natação, ciclismo, corrida — ficou justamente do lado que não ganhou pontos com o RH. [1][2][11]

6. Participação em comunidade religiosa: 22/35
Longevidade 4, Cardiometabólico 3, Cérebro 1, Mental 4, Social 5, Carreira 0, Acessibilidade 5.
Entra pelo mesmo critério de todo o resto, e o número é grande: HR 0,67 em 74.534 pessoas, com mortalidade cardiovascular e por câncer também menores. Empata com a raquete em pontos e perde no desempate por ter menos notas 5. Não leva 5 em longevidade porque a amostra é de enfermeiras americanas e o confundimento por seleção aqui é o pior da lista inteira. Se você é ateu, o achado útil não é "ache religião", é que a dose de contato humano recorrente e previsível parece ser o ingrediente ativo. [14]

7. Jardinagem e atividades na natureza: 19/35
Longevidade 3, Cardiometabólico 3, Cérebro 1, Mental 5, Social 3, Carreira 0, Acessibilidade 4.
A evidência randomizada mais forte de saúde mental da lista, e agora com respaldo de mortalidade que eu não tinha: HR 0,70 na coorte sueca. As notas 3 em corpo, e não 4, porque a exposição medida é atividade física não-exercício em geral, com jardinagem como um dos componentes, e não jardinagem isolada. [20][21][22]

8. Musculação + aeróbico combinados: 18/35
Longevidade 5, Cardiometabólico 5, Cérebro 2, Mental 3, Social 0, Carreira 0, Acessibilidade 3.
A melhor relação entre efeito e dose de toda a pesquisa: RR 0,60 com apenas 40 min/semana de força. Tem duas notas máximas, mais do que quase todo o top 10, e mesmo assim cai para 8º porque zera em social e carreira. É o exemplo perfeito de especialista — e a razão pela qual "só a academia" não basta. [17][19][23]

9. Tai chi: 17/35
Longevidade 0, Cardiometabólico 3, Cérebro 3, Mental 3, Social 3, Carreira 0, Acessibilidade 5.
O resultado mais contraintuitivo do ranking: um hobby sem nenhum dado de mortalidade empatando com a corrida e ganhando no desempate. Ele chega aqui por não zerar quase nada e por reduzir quedas (RR 0,76 em 24 ensaios) — um desfecho que meus sete eixos nem capturam e que, em idosos, é um dos maiores determinantes de perda de independência. [31][32]

10. Corrida: 17/35
Longevidade 4, Cardiometabólico 3, Cérebro 2, Mental 3, Social 0, Carreira 0, Acessibilidade 5.
HR 0,73, e 1x/semana já captura quase todo o efeito: a melhor relação benefício/tempo da lista junto com a musculação. Empata com o tai chi em pontos, em eixos zerados e em notas 5, e perde só no eixo social. Corre-se sozinho. [18]

Quem ficou de fora, e por quê

11. Ciclismo como transporte (17/35) — eu havia descartado ciclismo com HR 0,85, mas esse número é de ciclismo de lazer. No UK Biobank, com 263.450 pessoas, pedalar para o trabalho deu HR 0,59 de mortalidade e 0,55 de incidência de câncer. É o único hobby da lista com custo de tempo marginal zero, porque substitui um deslocamento que você já fazia. Empata em 17 e cai por não ter nenhuma nota máxima. [33]

12. Ter cachorro (16/35) — meta-análise de 3,8 milhões de pessoas com RR 0,76 de mortalidade [34], mas há uma reanálise publicada na mesma revista contestando a robustez da evidência [35]. O custo real e o compromisso de 10+ anos derrubam a acessibilidade.

13. Natação (15/35) — HR 0,72 geral e 0,59 cardiovascular, a melhor opção de baixo impacto para articulações. Especialista puro em corpo, solitária, e ainda precisa de piscina. [2]

14. Instrumento musical ou coral em grupo (15/35) — HR 0,64 para demência em meta-análise de 3 coortes [36], e ensaio randomizado com 390 idosos mostrou queda na solidão (ES 0,34) e ganho de propósito (ES 0,39) [37]. Perde para a natação no desempate por ter três eixos zerados contra dois. Reduzir risco de demência não é o mesmo que ficar mais inteligente [27].

15. Aprender uma habilidade nova e difícil (14/35) — o único item com evidência randomizada de ganho cognitivo contra controle ativo, e por isso nota 4 em cérebro, a mais alta do eixo junto com o voluntariado. Zera em corpo inteiro, o que o derruba. [29]

16. Leitura de livros (13/35) — HR 0,80 com dose-resposta por tercil e efeito mediado por cognição; livros funcionaram, jornais e revistas não. Quatro eixos zerados. Continua sendo o melhor uso possível de tempo sozinho, o que não é o que este ranking mede. [38]

E ficaram fora sem pontuar: xadrez e apps de treino cerebral, medidos contra controle ativo e sem funcionar [27][28]. Aprender um segundo idioma é um caso à parte: a evidência sugere atraso de cerca de 4 anos no aparecimento dos sintomas de demência, sem redução na incidência — adia a conta, não a cancela.

E o Brasil nisso tudo?

Fui atrás dos dados nacionais esperando descobrir que o brasileiro escolhe errado. Descobri o contrário.

Na PNAD do IBGE sobre práticas de esporte e atividade física, o esporte mais praticado no país é o futebol, com 15,3 milhões de pessoas (39,3% dos praticantes de esporte), e a atividade física mais praticada é a caminhada, com 13,8 milhões (49,1%) [39]. São, respectivamente, o 3º e o 2º colocados deste ranking. Academia e musculação vêm logo atrás, e correspondem ao 8º. Frequência a culto religioso, que é o 6º, é hábito semanal de 43% dos brasileiros [40]. E a leitura de livros, último colocado aqui, é também o hábito que mais encolheu: 53% da população não leu nem parte de um livro nos três meses anteriores à pesquisa, e só 20% usam o tempo livre para ler, contra 81% que usam para internet [41].

Ou seja: nenhum hobby brasileiro popular entra neste top 10 sem já estar nele, e os dois mais praticados do país ocupam o 2º e o 3º lugar. A convergência é quase suspeita de tão boa — futebol e caminhada são gratuitos, ao ar livre e feitos com outras pessoas, que é literalmente o padrão que a literatura premia.

O problema brasileiro, então, não é escolha de hobby. É volume: 62,1% da população não praticava esporte nem atividade física nenhuma, e o motivo mais citado por quem não pratica foi falta de tempo (38,2%) [39]. O ranking não serve para essas pessoas trocarem de hobby. Serve para mostrar que a opção número 2 da lista inteira custa zero e não exige agenda: é sair para caminhar com alguém.

A combinação que a evidência sustenta

O detalhe mais útil não está em nenhuma linha do ranking, e sim no cruzamento delas. O voluntariado é forte em quase tudo, mas suas duas notas mais baixas são cardiometabólico (3) e carreira (2). A caminhada em grupo tem exatamente o oposto: 5 em cardiometabólico e mental, 0 em carreira.

Somando o melhor de cada eixo, voluntariado + caminhada em grupo dá 31 de 35 — mais do que qualquer hobby isolado, e acima do 27 do primeiro colocado. As duas atividades são gratuitas, não exigem equipamento nem matrícula, e cabem em cerca de 3 horas por semana. O único eixo que continua fraco é carreira, e ele se resolve trocando a caminhada por um esporte coletivo, ou acrescentando um: aí a combinação vai a 32 de 35.

Repare no que isso significa para um país onde 38% dizem não ter tempo: as duas melhores escolhas de saúde disponíveis custam zero reais, e uma delas é caminhar.

Conclusão

Nenhum hobby vence sozinho em todas as dimensões, e é por isso que a pergunta certa não é "qual o melhor hobby?", e sim "qual o menor conjunto de hobbies que não deixa nenhum eixo em branco?". Por trás de todo o ranking há um padrão de três partes: intensidade pelo menos moderada, outra pessoa presente, mantido por anos. Os seis primeiros colocados têm todos nota máxima no eixo social, sem exceção. Nenhum dos quatro últimos tem.

Mas há um limite importante nesse padrão, e ele veio do estudo que mais contrariou minha própria tese: no Synapse Project, o grupo que só socializava não teve ganho cognitivo nenhum [29]. Companhia compra longevidade, pressão e humor. Não compra cérebro. Para cérebro parece ser preciso dificuldade e novidade — dança complexa, um instrumento, uma habilidade que você ainda não domina. E, pela revisão guarda-chuva de 2023, mesmo isso é menos garantido do que a literatura fazia parecer [25].

Então, se você só puder mudar uma coisa hoje, troque uma sessão solitária de academia por uma atividade física com outra pessoa junto. Você está comprando longevidade, cardiometabólico e social de uma vez, o que já é o melhor negócio da lista. Se quiser o eixo cognitivo também, ele custa separado, e o preço é aprender algo difícil.

Para quem passa o dia sentado, sozinho e olhando para uma tela, os eixos em branco são exatamente esses. A boa notícia é que os dois primeiros colocados são de graça, e o segundo é só uma caminhada com companhia.

Fontes

Schnohr P, et al. Various Leisure-Time Physical Activities Associated With Widely Divergent Life Expectancies: The Copenhagen City Heart Study. Mayo Clin Proc. 2018;93(12):1775-1785. https://pubmed.ncbi.nlm.nih.gov/30193744/
Oja P, et al. Associations of specific types of sports and exercise with all-cause and cardiovascular-disease mortality: a cohort study of 80 306 British adults. Br J Sports Med. 2017;51(10):812-817. https://pubmed.ncbi.nlm.nih.gov/27895075/
Merom D, et al. Dancing Participation and Cardiovascular Disease Mortality. Am J Prev Med. 2016;50(6):756-760. https://pubmed.ncbi.nlm.nih.gov/26944521/
Verghese J, et al. Leisure Activities and the Risk of Dementia in the Elderly. N Engl J Med. 2003;348:2508-2516. https://pubmed.ncbi.nlm.nih.gov/12815136/
Hewston P, et al. Effects of dance on cognitive function in older adults: a systematic review and meta-analysis. Age Ageing. 2021;50(4):1084-1092. https://pubmed.ncbi.nlm.nih.gov/33338209/
O'Reilly D, et al. Volunteering and mortality risk: a partner-controlled quasi-experimental design. Int J Epidemiol. 2017;46(4):1295-1302. https://academic.oup.com/ije/article/46/4/1295/3074984
Jenkinson CE, et al. Is volunteering a public health intervention? A systematic review and meta-analysis of the health and survival of volunteers. BMC Public Health. 2013;13:773. https://pubmed.ncbi.nlm.nih.gov/23968220/
Okun MA, Yeung EW, Brown S. Volunteering by older adults and risk of mortality: A meta-analysis. Psychol Aging. 2013;28(2):564-577. https://doi.org/10.1037/a0031519
Sneed RS, Cohen S. A prospective study of volunteerism and hypertension risk in older adults. Psychol Aging. 2013;28(2):578-586. https://pubmed.ncbi.nlm.nih.gov/23795768/
Carlson MC, et al. Impact of the Baltimore Experience Corps Trial on cortical and hippocampal volumes. Alzheimers Dement. 2015;11(11):1340-1348. https://alz-journals.onlinelibrary.wiley.com/doi/abs/10.1016/j.jalz.2014.12.005
Piopiunik M, Schwerdt G, Simon L, Woessmann L. Skills, signals, and employability: An experimental investigation. European Economic Review. 2020;123:103374. Versão de trabalho: IZA DP No. 11283, 2018. https://docs.iza.org/dp11283.pdf
Eather N, Wade L, Pankowiak A, Eime R. The impact of sports participation on mental health and social outcomes in adults: a systematic review and the 'Mental Health through Sport' conceptual model. Syst Rev. 2023;12:102. https://pmc.ncbi.nlm.nih.gov/articles/PMC10286465/
Hanson S, Jones A. Is there evidence that walking groups have health benefits? A systematic review and meta-analysis. Br J Sports Med. 2015;49(11):710-715. https://pubmed.ncbi.nlm.nih.gov/25601182/
Li S, Stampfer MJ, Williams DR, VanderWeele TJ. Association of Religious Service Attendance With Mortality Among Women. JAMA Intern Med. 2016;176(6):777-785. https://jamanetwork.com/journals/jamainternalmedicine/fullarticle/2521827
Holt-Lunstad J, Smith TB, Layton JB. Social Relationships and Mortality Risk: A Meta-analytic Review. PLoS Med. 2010;7(7):e1000316. https://journals.plos.org/plosmedicine/article?id=10.1371/journal.pmed.1000316
Holt-Lunstad J, et al. Loneliness and Social Isolation as Risk Factors for Mortality: A Meta-Analytic Review. Perspect Psychol Sci. 2015;10(2):227-237. https://journals.sagepub.com/doi/full/10.1177/1745691614568352
Momma H, et al. Muscle-strengthening activities are associated with lower risk and mortality in major non-communicable diseases: a systematic review and meta-analysis of cohort studies. Br J Sports Med. 2022;56(13):755-763. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9209691/
Pedisic Z, et al. Is running associated with a lower risk of all-cause, cardiovascular and cancer mortality, and is the more the better? A systematic review and meta-analysis. Br J Sports Med. 2020;54(15):898-905. https://pubmed.ncbi.nlm.nih.gov/31685526/
Pearce M, et al. Association Between Physical Activity and Risk of Depression: A Systematic Review and Meta-analysis. JAMA Psychiatry. 2022;79(6):550-559. https://jamanetwork.com/journals/jamapsychiatry/fullarticle/2790780
Ekblom-Bak E, Ekblom B, Vikström M, de Faire U, Hellénius ML. The importance of non-exercise physical activity for cardiovascular health and longevity. Br J Sports Med. 2014;48(3):233-238. https://pubmed.ncbi.nlm.nih.gov/24167194/
Rojas-Rueda D, Nieuwenhuijsen MJ, Gascon M, Perez-Leon D, Mudu P. Green spaces and mortality: a systematic review and meta-analysis of cohort studies. Lancet Planet Health. 2019;3(11):e469-e477. https://pubmed.ncbi.nlm.nih.gov/31777338/
Coventry PA, et al. Nature-based outdoor activities for mental and physical health: Systematic review and meta-analysis. SSM Popul Health. 2021;16:100934. https://pmc.ncbi.nlm.nih.gov/articles/PMC8498096/
Northey JM, Cherbuin N, Pumpa KL, Smee DJ, Rattray B. Exercise interventions for cognitive function in adults older than 50: a systematic review with meta-analysis. Br J Sports Med. 2018;52(3):154-160. https://pubmed.ncbi.nlm.nih.gov/28438770/
Erickson KI, et al. Exercise training increases size of hippocampus and improves memory. Proc Natl Acad Sci USA. 2011;108(7):3017-3022. https://www.pnas.org/doi/10.1073/pnas.1015950108
Ciria LF, et al. An umbrella review of randomized control trials on the effects of physical exercise on cognition. Nat Hum Behav. 2023;7:928-941. https://pubmed.ncbi.nlm.nih.gov/36973359/
Sommerlad A, et al. Leisure activity participation and risk of dementia: An 18-year follow-up of the Whitehall II Study. Neurology. 2020;95(20):e2803-e2815. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC7734721/
Sala G, Gobet F. Does Far Transfer Exist? Negative Evidence From Chess, Music, and Working Memory Training. Curr Dir Psychol Sci. 2017;26(6):515-520. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC5724589/
Simons DJ, et al. Do "Brain-Training" Programs Work? Psychol Sci Public Interest. 2016;17(3):103-186. https://pubmed.ncbi.nlm.nih.gov/27697851/
Park DC, et al. The Impact of Sustained Engagement on Cognitive Function in Older Adults: The Synapse Project. Psychol Sci. 2014;25(1):103-112. https://pubmed.ncbi.nlm.nih.gov/24214244/
Stensvold D, et al. Effect of exercise training for five years on all cause mortality in older adults: the Generation 100 study, a randomised controlled trial. BMJ. 2020;371:m3485. https://pubmed.ncbi.nlm.nih.gov/33028588/
Tai Chi for fall prevention and balance improvement in older adults: a systematic review and meta-analysis of randomized controlled trials. 2023. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC10509476/
Effects of Tai Chi and Qigong on cognitive and physical functions in older adults: systematic review, meta-analysis, and meta-regression of randomized clinical trials. BMC Geriatr. 2023;23:369. https://doi.org/10.1186/s12877-023-04070-2
Celis-Morales CA, et al. Association between active commuting and incident cardiovascular disease, cancer, and mortality: prospective cohort study. BMJ. 2017;357:j1456. https://pubmed.ncbi.nlm.nih.gov/28424154/
Kramer CK, Mehmood S, Suen RS. Dog Ownership and Survival: A Systematic Review and Meta-Analysis. Circ Cardiovasc Qual Outcomes. 2019;12(10):e005554. https://www.ahajournals.org/doi/full/10.1161/CIRCOUTCOMES.119.005554
Bauman A, et al. Does Dog Ownership Really Prolong Survival? A Revised Meta-Analysis and Reappraisal of the Evidence. Circ Cardiovasc Qual Outcomes. 2020;13(10):e006907. https://pubmed.ncbi.nlm.nih.gov/33079585/
Arafa A, et al. Playing a musical instrument and the risk of dementia among older adults: a systematic review and meta-analysis of prospective cohort studies. BMC Neurol. 2022;22:395. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9608922/
Johnson JK, et al. A Community Choir Intervention to Promote Well-Being Among Diverse Older Adults: Results from the Community of Voices Trial. J Gerontol B Psychol Sci Soc Sci. 2020;75(3):549-559. https://academic.oup.com/psychsocgerontology/article/75/3/549/5165411
Bavishi A, Slade MD, Levy BR. A chapter a day: Association of book reading with longevity. Soc Sci Med. 2016;164:44-48. https://pubmed.ncbi.nlm.nih.gov/27471129/
IBGE. Pesquisa Nacional por Amostra de Domicílios — Práticas de Esporte e Atividade Física, 2015. https://agenciadenoticias.ibge.gov.br/agencia-sala-de-imprensa/2013-agencia-de-noticias/releases/15128-falta-de-tempo-e-de-interesse-sao-os-principais-motivos-para-nao-se-praticar-esportes-no-brasil
Pew Research Center. Religion in Latin America / frequência a serviços religiosos no Brasil, 2024. https://www.pewresearch.org/
Instituto Pró-Livro / Itaú Cultural. Retratos da Leitura no Brasil, 5ª edição, 2024. https://www.prolivro.org.br/2024/11/19/tempo-livre-no-de-leitores-despenca-e-brasil-tem-menor-indice-em-23-anos/

Making of Tiny RPG Studio

André N. Darcie — Sun, 28 Jun 2026 17:42:59 +0000

This is the story of how I created Tiny RPG Studio: a small engine for simple RPGs, built to help people make their first games without needing to program.

At its core, it came from an idea that took me years to understand clearly: sometimes the best tool is not the one that lets you do everything, but the one that gives you just enough limits to finally finish something.

Childhood, RPG Maker, and the Static World

When I was a child, my aunt gave me a PC with Windows XP. I still did not have internet access, but I explored that computer as if it were the most interesting and exciting thing I could possibly have.

I used to ask people to download games for me. Once, I bought a rewritable CD and went to a friend's house because he had internet. He opened Baixaki, and we started looking for programs he could download so I could burn them to the CD and install them on my computer later.

I remember once telling my cousin: "the internet is magic, I can download anything, learn about anything, and one day, when I have it, no one will stop me."

While browsing Baixaki, a Brazilian download site, I saw a category that caught my attention: "game creators." At the time, I was already addicted to PlayStation 1, playing Resident Evil and Silent Hill, so the idea that I could create my own games felt insane.

I downloaded things like Engine 001 and RPG Maker.

RPG Maker was incredible because it already came with ready-made sprites, an RTP package with characters, maps, objects, and amazing pixel art. I did not know pixel art, so that whole visual side was already partly solved for me.

I quickly learned how to build visually interesting maps with sprites, place NPCs in the world, and write dialogue for them. At that point, I really had my first game, and that felt like an unprecedented idea.

I remember telling a cousin: "I found a different kind of game, where you create games inside it." In other words, I did not really understand the concept of a game engine yet.

Eventually, I reached a point where I had created that world, but everything was static: the scenery, the NPCs, the monsters, even the story. Everything existed, but nothing could change.

I wanted to do something simple and even a bit cliche: a king in his castle would ask me to kill a dragon that was terrorizing the village. So I would go there, defeat the dragon, and come back to talk to the king.

But the king did not know I had done it.

And I asked myself: how could I solve this?

Searching through forums and tutorials on Google, I found something called "Switches." They could have two states: ON and OFF.

So when I defeated the dragon, I would turn the Switch ON. When I returned to the king, he had his default dialogue, but he also had an alternate dialogue if the Switch was ON. Something like: "You killed the dragon and saved the village."

I did not know exactly what I was doing, but it worked. So I started creating switches for all kinds of things, even to check whether it was day or night in the game world.

Discovering Programming

Much later, I started a technical IT program, a two-year course I took alongside high school. I wanted to learn programming.

That had a big impact on me because, at that point, the computer meant everything to me, but I was still just a passive user, using things created by other people. The idea that I could become a programmer and create things from my own ideas, for other people to use, felt surreal.

In the first programming logic classes, the teacher explained what a conditional is, what an IF is: if yes, do this; otherwise, do that.

Before that, instructions felt like a fixed sequence, like a recipe. But then something new appeared: a branch in the flow. A condition.

And I had a huge epiphany.

That Switch from RPG Maker was exactly the conditional I had been using to change the king's dialogue. So, in a weird way, I already knew programming long before I knew that I knew programming.

I even remember writing some code and asking the teacher what he thought. He said: "Everyone, this is interesting. He did it differently from how I taught it, but it will also work. This shows that there are many ways to write code."

Aside from art class in elementary school, that was the second time in my life I started getting praised in class. It happened in programming class, not because I was great at math or logic, but because I had already learned all of that from RPG Maker.

Bitsy and the Value of Limitations

Then came a big time jump. I had already graduated in computer science, was working my first job as a programmer, and was creating small game projects with plain code, now in JavaScript. I also knew how to make games in Unity with C#.

Through those projects, I discovered itch.io, which is huge, and found tools like Twine, for creating text games with choices; PICO-8, a fantasy console for making retro minigames; and Bitsy, a tiny engine for creating narrative games with three colors and simple pixel art.

Bitsy gave me another epiphany.

I used to think that creating a game engine like Unity or Unreal was an absurd idea. My role was to be a high-level application developer. I do not consider myself a programming genius like Linus Torvalds with the Linux kernel, so learning low-level GPU programming just to consider creating an engine felt way too distant.

But I had never stopped to think about creating a high-level engine in JavaScript, using Canvas, where all the low-level details could be ignored. The focus could be something else: creating an accessible tool, easy to use, and capable of running even on a phone.

An engine that is simpler to build and also simpler for people to make games with. No need to know programming. No need to take courses or watch tutorials just to build something basic.

I immediately thought: "I wish I were the person who created Bitsy, because that idea is absurdly brilliant."

Instead of competing with RPG Maker, Godot, or Unity by trying to offer more features, more performance, and more tutorials, Bitsy goes in the opposite direction. It serves the needs those tools do not serve as well: accessibility, simplicity, and a very low barrier to entry.

One of the best games I ever created was Zero to One, made in Bitsy for a game jam called One Room.

It was the best game I had created precisely because I never managed to finish my more ambitious games, the ones with long scripts, lore, worlds, systems, and brilliant ideas.

I am very bad at creating something with a limited scope. I define a scope and immediately want to expand it with incredible ideas that appear all the time. I take a shower and come back with five more ideas for the game. That makes the game impossible to finish. After a few months, I give up and already want to make another game that feels even more brilliant.

But Bitsy does not let that happen so easily. It is limited by default. You are forced to reduce the scope and tell a direct story there.

So I wrote a simple script, created three scenes, finished the game, and released it within the limited time of the game jam.

In other words, all my problems were solved there: I finally had a solid little game released online.

Bitsy stands alongside major engines in terms of the number of games created precisely because it is easy and fast to make something and release it. Without a doubt, it helped people who had never thought about creating games actually create games.

Taking a Break from Game Dev

After years of making games, after creating paid games and taking Godot courses, after deciding that my biggest life goal was to release a game on Steam, I gave up on game dev.

Imagine spending every night for a year creating a game, putting effort and work into it, and in the end, after a year and a half, having only the beginning of a game. The art was not ready, the gameplay was not smooth enough, and the puzzles were not good.

Once again, I had been too ambitious and could not finish my game.

After that, I thought: how many games are released on Steam? On itch.io, how many brilliant games appear every day? Does the world need more games? Or does it specifically need my games?

The work, bureaucracy, and frustration you need to go through just to make a simple game are heavy. That is why I completely gave up on it for a while.

Returning with AI

The arrival of AI had a major impact on programming. I started using ChatGPT to help me create C# classes, write SQL queries for work, and solve project errors.

You know that annoying error you have no idea how to solve? Before, I would go to Google, read several forums and posts, then go to Stack Overflow, find nothing, think about asking a question, and already imagine getting torn apart in the replies.

That summed up my experience as a programmer pretty well: moments of joy and moments of frustration.

Then I started copying the entire error message and sending it to ChatGPT. It gave specific and useful solutions. I would go back, apply them, and solve the issue. It was rudimentary, but it worked.

Over time, I began to realize that many errors could be solved in record time. When a coworker asked me for help, I would send their error to ChatGPT and solve it in minutes. Sometimes they had spent the entire day stuck on it.

They would say: "wow, you solved my error that fast? I lost the whole day on this, you really are a programming genius." I would laugh and say: "I sent it to the chat."

After a while, everyone started doing the same thing and no one asked me for help anymore.

I became excited about the potential of AI to remove the frustrating part I never liked and let me focus on the part where I could be better: being creative, having ideas, and giving direction.

When GPT-5 came out, I started creating small web games with HTML, JS, and CSS directly through chat. This was in 2025. I found it fascinating and applied the same philosophy of small projects: creating minigames and short stories.

I had the idea of creating a mini-RPG using Canvas, based on my previous projects. It quickly created something playable, and then I thought: now we need a small editor for this, so I can actually create this game properly.

And it did.

It was a small MVP, made with a one-shot prompt, but it turned out well and, surprisingly, it worked.

I left the project aside for a while, until I realized that, for it to become something real, I needed to take it out of the chat, put it in an editor like VS Code, and start working on it properly.

At the time, everyone was talking about Cursor, a fork of VS Code focused on working with AI. I downloaded it, got the free version with some credits, and put the project there. It started evolving brutally fast.

I showed the project to Diego and he doubted it: "I want to see if this is really working." It looked magical and had been made too quickly.

But when I tried to add something new, the project broke badly. I kept asking the AI to fix it, tried several prompts, and nothing worked. Since the code had been generated by AI, I also did not understand everything, and fixing it alone would take a lot of time.

At the time, I thought: "I hit the limit of AI here."

Then tools like Claude Code and Codex arrived, with agents better prepared to work on code projects. When I saw that Codex was available for ChatGPT subscribers, I came back to the project.

Codex solved the fatal bug, improved a few things, and got the tool ready to launch in just a few days.

We have to consider that I had already given up on game dev. My routine had become that of an adult with no time for unpaid personal projects. Spending nights fixing bugs and debugging was no longer realistic.

So I saw that the most tedious manual work could be handled by AI, while I focused on being creative, having good ideas, expressing myself as an artist, and applying software engineering. That is the reason I came back to game dev and to the community, and why I felt it was worth creating a small game engine.

This project would not exist without the beginning with GPT-5 and the maintenance with Codex.

Launch, Community, and Engineering

Since the engine was an MVP, a prototype, there was still a lot to polish, improve, and fix.

Diego, who has always played my games and projects, started collaborating a lot. He helped the tool become good enough to launch, not only by testing and finding bugs, but also by helping solve code problems, giving constant feedback, and promoting it through game jams.

I think that made the difference between the engine being seen by someone and being completely forgotten among millions of projects out there.

In the end, promotion is one of the most important parts of a project. As the saying goes, "marketing is the soul of the business." If you create an incredible tool and no one knows it exists, what is the point?

By the end of 2025, the engine had already launched. People were creating games with it, game jams were happening, the community was growing, and I even posted about it on LinkedIn.

Then came the part I value most in the project: applying my knowledge of programming, software engineering, and best practices to turn it into something beyond a prototype.

Until that point, I had mostly been deciding the creative direction and how the features would work. I had not yet thought that much about code and architecture, because it was a simple project made for people who do not have much time.

But with the success of the tool, I decided to apply everything I knew about code. It was fascinating, because I learned things that I took to work, presented in a talk, and used to help other developers: how to build something high-quality with the help of AI agents.

I decided to try Claude Code, paying for it instead of using a free version, because there is no such thing as a free lunch. I made the biggest migration in the history of the project, moving the entire codebase to TypeScript, with aggressive linting, unit tests, functional tests, and a code quality pipeline.

I created an architecture, organized folders and structure, applied SOLID, and started using best practices I had learned from college and from every company I had worked at.

That was when the project became much more robust. If I change something that breaks something else and creates a bug, I find out immediately, because there are tests covering many scenarios.

In that second phase, the engine became a serious project, something people could use and trust. With the game jams hosted by Diego, promotion gained strength, and today we have a very active community using the engine every day.

The Philosophy of Tiny RPG Studio

The philosophy of Tiny RPG Studio is the same one from the beginning of this post: creating an accessible tool for people who are just starting out.

I created a game in RPG Maker, used boolean variables, used Switches, and it was so easy that I did not even know it could already be considered programming.

The sprites already existed. I did not need to know pixel art or programming. Even so, I was able to create stories and adventures.

Now I have reached a point in life where I can create my own engine for other people to use. Maybe it will be their RPG Maker. Maybe it will be the first engine of their lives. Maybe it will be where they create the first game they actually finish.

I would never try to create an RPG Maker competitor, the same thing but better. That would be impossible. But I could take the minimalist philosophy of Bitsy and create something in that direction.

In the end, creativity is also about building on solid and brilliant things other people made before you, standing on the shoulders of giants, and then adding your own special touch.

I feel that Tiny RPG Studio is something new because it is absurdly simple to use.

You do not need even the bare minimum of pixel art, programming, or knowledge of how to create a scene with a teleport event from one place to another.

The game world is fixed, limited, and already interconnected, like a tiny open world. Even that comes built in.

The interface is simple and intuitive even on a phone, because the project was born mobile-first. And because I still think generating an HTML build, downloading it, and hosting it is too much work, the engine focuses more on generating a URL.

You create your game, generate a URL, and send it to your friends. The URL already contains the entire game. There is nothing else to download.

I cannot imagine a simpler way to create a mini-RPG, and I feel very proud of this project.

In the end, Tiny RPG Studio was born from this cycle: discovering games, discovering programming, giving up on projects that were too big, and coming back with a tool small enough to actually exist.

If it helps someone create the first game of their life, then it was already worth it.

O mínimo que você precisa saber para desenvolver software com IA

André N. Darcie — Sat, 27 Jun 2026 12:18:58 +0000

⏱️ Tempo de leitura: aproximadamente 3 minutos.

Seja um engenheiro de software. A IA é uma ferramenta, não substitui conhecimento de arquitetura, engenharia e boas práticas.
Não terceirize decisões para a IA. Requisitos funcionais e não funcionais devem ser definidos por você. Seja específico e pense até nos menores detalhes.
Não existe almoço grátis. Modelos gratuitos, versões mais baratas ou rodar modelos locais ainda ficam atrás dos melhores modelos para desenvolvimento profissional.
Hoje, os modelos mais viáveis para engenharia de software são o Opus e o GPT usando o maior nível de raciocínio ("high effort"). Utilizar modelos inferiores geralmente aumenta o retrabalho, fazendo você gastar mais tempo e consumindo o tempo de outras pessoas revisando e corrigindo erros.
Use agentes de IA rodando no seu computador. O harness faz uma diferença enorme na qualidade. Para GPT, use o Codex. Para Opus, use o Claude Code. Ferramentas com harness inferior normalmente entregam resultados inferiores, mesmo usando o mesmo modelo. Afinal, por que uma empresa terceirizada conseguiria criar uma ferramenta que extrai mais de um modelo do que a própria empresa que o desenvolveu?
Planos mais baratos de IA servem para projetos simples ou amadores. Em projetos profissionais, considere investir em planos que ofereçam acesso aos melhores modelos e maior capacidade de uso.
Todo projeto deve possuir um CLAUDE.md ou AGENTS.md. Mantenha esse arquivo curto, objetivo, em inglês e contendo apenas as informações realmente importantes do projeto.
Nunca implemente diretamente. Analise o problema, crie um plano, revise esse plano e só então implemente. O plano deve conter arquitetura, critérios de aceitação, testes, validações e feedback loops.
Seja cético com o plano. Revise tudo antes de implementar. Peça para a IA identificar lacunas, fazer perguntas e desafiar suas decisões. A IA só deveria errar por não seguir um plano bem definido.
Desenvolva senso crítico. A IA acelera a execução, mas não substitui julgamento, criatividade e decisões de engenharia.
Mude seu papel. Deixe de ser apenas quem implementa tarefas. Passe a atuar como arquiteto, tech lead e product owner, pensando no sistema como um todo.
Contexto é tudo. Um único prompt não basta. Forneça regras de negócio, arquitetura, convenções, exemplos e restrições, mas apenas o que for realmente relevante para a tarefa. Contexto insuficiente reduz a qualidade das respostas, enquanto contexto desnecessário aumenta custo, dificulta o foco do modelo e pode piorar os resultados.
Prefira evoluir em pequenas etapas. Em vez de pedir uma funcionalidade inteira de uma vez, divida o trabalho em incrementos pequenos, valide cada etapa e só então avance para a próxima. Isso reduz retrabalho, facilita revisões e aumenta a qualidade do resultado final.
Sempre valide automaticamente. Todo ciclo deve terminar executando build, testes, linters, formatadores e análise estática.
Não aceite código apenas porque funciona. Exija legibilidade, simplicidade, segurança, observabilidade, testes e manutenibilidade.
Use skills para padronizar prompts. Elas evitam que você precise reescrever instruções repetitivas para tarefas feitas constantemente, mantendo o mesmo padrão de qualidade, arquitetura e validação em todos os projetos.
Se analisar, planejar, revisar e testar parece trabalho demais para você, talvez não valha a pena usar IA para desenvolver software. Sem esse processo, a tendência é gerar código de baixa qualidade, aumentar o retrabalho e criar problemas que custarão muito mais tempo para corrigir depois.
A responsabilidade é sempre sua. No final, você é responsável por cada linha de código que chega à produção. Não culpe a IA, as ferramentas ou terceiros. No fim, quem a empresa vai cobrar é você.

A IA não vai pensar por você. E isso é uma coisa boa.

André N. Darcie — Fri, 26 Jun 2026 16:21:58 +0000

Eu vejo muita gente esperando que a IA aja como um engenheiro de software sênior. Que ela tome decisões de arquitetura, escolha as melhores práticas, pense em escalabilidade, segurança, performance... tudo sozinha.

Sinceramente, eu acho que essa expectativa está errada.

No funcionamento mais básico, um LLM pega o seu prompt e prevê os próximos tokens mais prováveis. Depois existe o pós-treinamento, com validação humana, mas no fim ela continua sendo guiada pelo que você escreveu.

E aí vem o ponto.

Se você não disse que queria SOLID, por que ela deveria aplicar SOLID?

Se você não pediu Repository Pattern, por que ela deveria criar um?

Se você pediu uma API simples, por que ela deveria gastar mais tokens criando uma arquitetura cheia de camadas?

Ela estaria assumindo coisas que você nunca pediu.

E assumir coisas nem sempre é bom.

Todo mundo pensa apenas no lado positivo:

"Seria legal se a IA tomasse boas decisões sozinha."

Mas existe o outro lado.

Ela pode decidir usar uma biblioteca que você não queria, criar dependências desnecessárias, aumentar a complexidade do projeto ou até gerar um vendor lock-in que você nunca escolheu.

É por isso que eu acho que a IA não deveria decidir essas coisas por conta própria.

Ela deveria executar exatamente o que você pediu.

Por exemplo, quando eu quero adicionar logs em um projeto, eu não escrevo simplesmente:

"Adicione logs."

Eu escrevo algo mais próximo de:

Utilize Serilog, siga a documentação oficial, implemente seguindo as boas práticas da biblioteca e mantenha o padrão do projeto.

Agora sim ela tem contexto.

Ela sabe qual biblioteca usar, qual documentação seguir e qual padrão eu espero.

O mesmo acontece com qualidade de código.

Se eu fico uma semana inteira pedindo só feature, feature, feature, feature... o débito técnico vai aparecer.

Mas a culpa não é da IA.

Eu nunca pedi para ela reorganizar o projeto.

Eu nunca pedi um code review.

Eu nunca pedi para separar responsabilidades.

Então, de tempos em tempos, eu paro e faço prompts específicos para qualidade.

No Tiny Theft Auto (meu pequeno projeto inspirado em GTA) foi exatamente assim.

O projeto começou como um único index.html.

Quando eu decidi que ele iria crescer, fui eu quem falou:

aplique o SRP;
separe uma classe por arquivo;
reorganize toda a estrutura;
faça um code review;
levante pontos de melhoria para eu decidir se vale a pena corrigir.

Essas decisões foram minhas.

A IA só executou.

Isso acontece também em empresas.

No meu trabalho, por exemplo, existem padrões internos para logs, observabilidade, testes e várias outras coisas.

Eu não espero que a IA adivinhe qual padrão usar.

Eu passo a documentação, a skill ou o template da empresa e peço para ela seguir aquilo.

Ela deixa de "inventar" arquitetura e passa a implementar o padrão que já existe.

No fim, eu acho que a maior mudança de mentalidade é essa:

Nunca terceirize pensamento. Terceirize o braço.

Quem decide arquitetura é você.

Quem decide escalabilidade é você.

Quem decide boas práticas é você.

Quem decide qual biblioteca usar é você.

A IA serve para executar essas decisões com muito mais velocidade.

Porque, no fim das contas, ela não é um engenheiro de software tomando decisões por você.

Ela é um multiplicador da produtividade de quem sabe exatamente o que quer construir.

Claude Fable 5 me permitiu criar GTA em apenas um prompt.

André N. Darcie — Tue, 09 Jun 2026 21:02:35 +0000

Claude Fable 5 me permitiu criar um "GTA" em apenas um prompt.

Prompt:
"Crie um jogo, Tiny GTA 3D."
A própria Anthropic afirma que o Fable 5 é seu modelo mais poderoso já lançado ao público, com avanços significativos em engenharia de software, pesquisa científica, visão computacional e execução autônoma de tarefas complexas. Em testes iniciais, empresas relataram que o modelo foi capaz de comprimir meses de trabalho de engenharia em poucos dias.

Cidade 3D aberta com 64 quarteirões, prédios, parques e oceano
Dirija, roube carros e fuja da polícia
Sistema de procurado com 5 estrelas, viaturas e helicóptero te perseguem
42 pedestres vivos que fogem, voam e morrem
16 missões de entrega com histórias de corrupção brasileira
Áudio sintetizado: motor, sirene, buzina e cantada de pneu
Recorde salvo no navegador

Jogue aqui: https://andredarcie.github.io/tiny-gta/

Ideias Valem Muito Menos do Que Você Imagina [PT-BR]

André N. Darcie — Sat, 30 May 2026 21:19:18 +0000

A notícia da venda do Downdetector e do Speedtest para a Accenture por US$ 1,2 bilhão trouxe um comentário que aparece sempre que uma empresa de software faz sucesso:

"Mas eu consigo programar isso em um fim de semana."

Talvez consiga mesmo.

Mas isso não significa que você conseguiria construir o negócio.

O software é apenas uma pequena parte.

Criar um site que mede velocidade de internet não é particularmente difícil para um desenvolvedor experiente.

Existem diversos clones e projetos open source que fazem algo parecido.

O próprio fundador de um concorrente da Ookla comentou que criou sua primeira versão durante um fim de semana em 2008.

O detalhe importante é que ele levou 18 anos para transformar aquilo em um negócio relevante.

O que realmente tem valor?

Mas o valor normalmente está em outros lugares:

Distribuição
Marca
Confiança dos usuários
Relacionamento com empresas
Estratégia comercial
Dados acumulados ao longo dos anos

O verdadeiro produto eram os dados

Segundo pessoas do setor, o principal negócio não era o teste de velocidade em si.

Milhões de usuários realizam testes diariamente e geram informações valiosas sobre redes de internet ao redor do mundo.

Esses dados ajudam operadoras a identificar gargalos, comparar desempenho e planejar investimentos.

É por isso que empresas pagam valores altos para ter acesso a essas informações.

Conclusão

A ideia do Speedtest cabe em uma frase.

Se um desenvolvedor construiu um concorrente em um fim de semana em 2008, imagine agora com agentes de IA. Ainda assim, continuarão faltando os 18 anos necessários para transformar aquilo em um negócio vendável.

Afinal, transformar isso em uma empresa bilionária exigiu décadas de execução, operação, marketing, vendas, infraestrutura e construção de confiança.

Ideias são abundantes, podem ser criadas e roubadas o tempo todo.

Execução é rara.

Agentes de IA exigem TDD: o passo a passo necessário para aplicar na prática [PT-BR]

André N. Darcie — Tue, 17 Mar 2026 20:59:35 +0000

Este tutorial mostra como usar um agente de IA para praticar TDD do zero, partindo de um requisito escrito em linguagem simples até uma implementação refatorada e com testes passando.

O exemplo é um caso de uso simples/abstraido: criar conta de usuário.

O que é TDD?

TDD (Test-Driven Development) é uma técnica de desenvolvimento em três fases:

Fase	O que fazer
RED	Escrever os testes antes do código. Eles devem falhar.
GREEN	Escrever o mínimo de código para os testes passarem.
REFACTOR	Melhorar o código sem quebrar os testes.

Ameaça e defesa

Passo 1: Definir os requisitos

Antes de escrever qualquer código, escreva o que o sistema precisa fazer em linguagem simples. Use a IA para transformar isso em um documento de requisitos.

Prompt:

Crie um arquivo .md simples, listando os requisitos
necessários para criar um caso de uso de criar 
conta de usuário com nome, e-mail e senha,
apenas com o básico.

Resultado:

# Criar Conta

## O que é isso?
Permite que uma pessoa crie uma conta na plataforma informando seu nome, e-mail e senha.

## O que o usuário precisa informar?
- Nome
- E-mail
- Senha

## Quando o cadastro é recusado?

| Situação | Motivo |
|----------|--------|
| Nome não foi preenchido | O nome é obrigatório |
| Nome tem menos de 3 letras | Nome muito curto para ser válido |
| E-mail não foi preenchido | O e-mail é obrigatório |
| E-mail está no formato errado | Precisa seguir o padrão nome@dominio.com |
| E-mail já foi usado em outro cadastro | Cada conta precisa ter um e-mail único |
| Senha tem menos de 8 caracteres | Senha muito curta |
| Senha não tem letras e números ao mesmo tempo | Senha fraca demais |

## O que acontece quando o cadastro dá certo?
A conta é criada e o sistema confirma com:
- Código único da conta
- Nome cadastrado
- E-mail cadastrado
- Data e hora do cadastro

Dica: Antes de avançar, pergunte à IA se faltou algum edge case. Requisitos incompletos geram testes incompletos.

Outra dica: Peça para um modelo de IA diferente do que você está usando revisar os requisitos e apontar falhas graves, contradições ou cenários não cobertos. Modelos diferentes cometem erros diferentes.

Prompt:

Faltou alguma coisa importante que não considerei? Algum edge case?

Passo 2: Visualizar o fluxo

Com os requisitos prontos, gere um fluxograma para validar o entendimento antes de escrever código.

Prompt:

Com base no arquivo .md criado, crie um fluxograma
da esquerda para a direita exemplificando o fluxo.

Resultado:

Por que isso importa? O fluxograma torna visível a ordem das validações e os caminhos de erro. É mais fácil revisar um diagrama com o time do que revisar código.

Passo 3: Criar a classe sem implementação (RED)

Crie apenas o esqueleto da classe, com as dependências e a assinatura do método, sem nenhuma lógica. O método deve lançar NotImplementedException.

Prompt:

Crie a classe de Caso de Uso sem implementação alguma no método,
apenas com as dependências possíveis com base nos requisitos.

Resultado:

public class CreateUserUseCase
{
    private readonly IUserReadRepository _readRepository;
    private readonly IUserWriteRepository _writeRepository;
    private readonly IPasswordHasher _passwordHasher;

    public CreateUserUseCase(
        IUserReadRepository readRepository,
        IUserWriteRepository writeRepository,
        IPasswordHasher passwordHasher)
    {
        _readRepository = readRepository;
        _writeRepository = writeRepository;
        _passwordHasher = passwordHasher;
    }

    public Task<Result<CreateUserResponse>> ExecuteAsync(CreateUserCommand command)
    {
        throw new NotImplementedException("Implementação pendente");
    }
}

Passo 4: Escrever os testes (RED)

Com a classe vazia criada, peça à IA para escrever os testes baseando-se nos requisitos. Os testes devem falhar neste momento, isso é esperado e correto.

Uma observação sobre o ritmo: no TDD clássico, o ciclo é executado um teste por vez: escreve um teste, faz passar, refatora, repete. Aqui estamos escrevendo todos os testes de uma vez antes de implementar, o que é uma adaptação prática para trabalhar com IA.

Prompt:

Com base no arquivo de requisitos e nessa classe de caso de uso,
escreva os testes unitários que validem cada requisito seguindo o padrão Arrange-Act-Assert, e confirme que eles estão falhando.

Resultado: testes falhando:

Antes de avançar, verifique se a cobertura está completa.

Prompt:

Esses testes estão cobrindo totalmente os requisitos
ou faltou algum caso?

Regra de ouro do TDD: só avance para o GREEN depois que todos os testes estiverem escritos e falhando pelo motivo certo: NotImplementedException, não erro de compilação.

Passo 5: Fechar o agente e abrir uma nova sessão

Antes de implementar, feche o agente completamente e abra uma nova conversa ou limpe o contexto do agente, por exemplo com /clean.

Na fase GREEN, a única fonte da verdade é o teste. Não o requisito, não o fluxograma, não a conversa anterior.

Passo 6: Implementar para passar nos testes (GREEN)

Na nova sessão, mostre apenas os testes e a classe vazia. O objetivo aqui é apenas fazer os testes passarem, sem se preocupar com qualidade, padrões ou boas práticas ainda.

Prompt:

Com base nos testes unitários existentes para a criação de usuário,
crie a implementação do caso de uso.

Resultado: testes passando:

Importante: nesta fase é normal o código ficar feio. Validações inline, strings hardcoded, acoplamentos diretos, tudo isso é esperado. O que importa é: os testes passam.

Passo 7: Identificar os problemas (REFACTOR)

Com os testes verdes, peça à IA para revisar o código com olhar crítico.

Pergunte o que está errado, não se está certo. Modelos de IA tendem a confirmar o que o usuário quer ouvir. "O código está bom?" quase sempre recebe um "sim". "Quais são os problemas?" força uma análise real.

Prompt:

Liste os problemas encontrados no código implementado
com base nas boas práticas de desenvolvimento.

Resultado:

Passo 8: Refatorar (REFACTOR)

Com a lista de problemas em mãos, peça à IA para corrigi-los. Os testes são a rede de segurança: se alguma refatoração quebrar o comportamento, os testes vão acusar imediatamente.

Refatorar é mudar como, não o quê. O comportamento externo deve permanecer idêntico antes e depois. Se um teste quebra durante a refatoração, significa que ele estava testando um detalhe interno de implementação em vez do comportamento, e provavelmente precisa ser revisado junto com o código.

Prompt:

Refatore esses pontos de melhoria no código.

Resultado:

Os problemas encontrados foram violações de SRP (uma classe deve ter apenas uma responsabilidade), OCP (aberto para extensão, fechado para modificação), ISP (interfaces não devem forçar dependências desnecessárias), DIP (dependa de abstrações, não de implementações concretas), DRY (não repita a mesma lógica em lugares diferentes) e um problema de segurança com salt fixo na senha.

Passo 9: Confirmar que tudo ainda passa

Após a refatoração, rode os testes novamente para garantir que nenhum comportamento foi quebrado.

Prompt:

Execute novamente todos os testes.

Resultado: 24/24 passando:

Passo 10: Testar manualmente e em homologação

Com os testes automatizados passando, valide o comportamento real da feature em ambiente de homologação ou por meio de testes manuais. Ferramentas e integrações que os testes unitários não cobrem só aparecem aqui.

Se algo der errado, não tente corrigir diretamente no código. Volte ao Passo 1 e trate o bug como uma nova demanda:

Descreva o comportamento incorreto como um requisito, o que deveria acontecer e o que está acontecendo, volte para o passo 1.

Por que isso importa? Um bug corrigido sem teste pode voltar sem que ninguém perceba. O teste que comprova o bug é a garantia de que ele nunca mais vai passar despercebido.

Conclusão

O ciclo completo ficou assim:

Requisitos → Fluxograma → Esqueleto → Testes falhando
→ Fechar agente → Implementação passando → Refatoração → Testes passando

TDD com IA significa usar o agente de IA para acelerar cada etapa do ciclo enquanto você, desenvolvedor, mantém o controle das decisões importantes: o que o sistema deve fazer, quais casos precisam ser testados e quando o código está bom o suficiente para ir para produção.

TDD Is No Longer Optional in the World of AI Agents

André N. Darcie — Mon, 16 Mar 2026 19:00:54 +0000

Test-Driven Development (TDD) is a development practice where you write tests before writing the code. The cycle is simple: write a failing test, implement the minimum code to make it pass, refactor. Repeated in a loop, this ensures the code does exactly what was specified.

A lot of people use AI like this: send the finished class and ask it to generate tests.

The problem is that the model is just completing a token puzzle. It generates tests that match the existing code, not necessarily the correct behavior.

For the model, it's not really understanding the system. It's just trying to predict the next likely token. So the test ends up being just a logical continuation of the code.

Inverting the process

What worked for me was inverting this using TDD.

The agent reads the functional requirements.
The agent generates tests based on those requirements.
I clear the context (new agent, blank context).
I ask it to implement the code that makes the tests pass.

At this point the agent has only one clear goal: make the tests pass.

It tries, fails, tries again, in a loop, until it succeeds.

Why this works

This works because tests are deterministic. For the same code, the result will always be the same.

Agents are not deterministic. There is randomness, there is hallucination, and we don't have full control over what the model will generate.

So everything we can build to contain that behavior helps.

Tests end up being exactly that: a kind of cage to control the chaotic behavior of agents.

Bugs too

I've used this approach in critical projects where bugs simply weren't an option. The flow was: first have the agent create a test that actually breaks and reproduces the problem. Only then ask it to fix it.

Because if you just ask the AI to "fix the bug," it might simply invent a solution and claim it worked.

But tests don't lie.

Tests create a forced feedback loop.

A good practice that became mandatory

In the world of AI agents, TDD has gone from being an optional good practice to being practically mandatory.

With AI-generated code, we saw a boom in automated tests. That made a big difference: code without tests lost value, because generating tests no longer costs anything. But we can go a level higher. Instead of generating tests for code, we generate tests for requirements. That's TDD, and it's the next step.

Qwen3.5 rodando localmente: super rápido e com ótima qualidade

André N. Darcie — Sun, 08 Mar 2026 15:11:31 +0000

Testei o Qwen3.5 rodando localmente e fiquei impressionado.

Resolvi testar o novo modelo open source Qwen3.5 no meu notebook, sem muita pretensão. A ideia era só ver como ele se comportava rodando localmente.

O que aconteceu me surpreendeu bastante: ele é brutalmente rápido.

As respostas vinham tão rápidas e tão boas que em um momento eu parei e fui conferir se aquilo realmente estava rodando em localhost ou se, por algum motivo, estava chamando alguma API externa. Mas não. Era tudo local mesmo.

Exemplo:

LLM local

O Qwen3.5-9B é desenvolvido pela Alibaba e tem 9 bilhões de parâmetros. Suporta 256K tokens de contexto e 201 idiomas.

Uma IA rodando 100% offline no notebook, sem API, sem custo e sem enviar dados para lugar nenhum.

Hardware

RTX 3060 Laptop (6GB VRAM)
16GB RAM
Windows 11

Stack

Modelo: Qwen3.5-9B UD-Q4_K_XL (Unsloth Dynamic 4-bit)
Runtime: llama.cpp com CUDA
Interface: llama-server com web UI em localhost:8080

Performance

A performance ficou em torno de 45 tokens por segundo, rodando completamente na GPU.

Para um notebook, isso é impressionante.

Instalação

Segui o guia oficial da Unsloth para rodar o modelo:

https://unsloth.ai/docs/models/qwen3.5

Foi bem direto de configurar.

Impressão geral

A sensação é que LLMs locais realmente estão chegando em um nível muito prático de uso. Rodar um modelo desse porte offline, no próprio notebook, com essa velocidade e qualidade de resposta, é algo que até pouco tempo atrás parecia distante.

E agora está simplesmente rodando em localhost.

A IA fez o trabalho de vários membros da minha equipe, e isso vai gerar demissões

André N. Darcie — Fri, 13 Feb 2026 12:25:03 +0000

A lógica é simples: se uma IA poderosa operada por 1 pessoa substitui a produtividade de uma equipe de 10, então podemos demitir 9 e está tudo resolvido?

Não.

Seguindo essa mesma lógica, 10 pessoas usando IA produziriam como 100. E se o seu concorrente fizer isso enquanto você reduz equipe, você acabou de se colocar em desvantagem.

Ao demitir porque “a IA já entrega o mesmo que o time atual”, a empresa está presa à fotografia de hoje. Só que a régua mudou.

Uma concorrente que mantenha seus desenvolvedores e os potencialize com IA não apenas preserva a capacidade de entrega, mas amplia velocidade, qualidade e experimentação. Enquanto isso, a empresa que encolhe o time corre o risco de ver seu produto evoluir mais lentamente, tornar-se superficial e perder competitividade.

Gone Home: o jogo que destruiu as regras e construiu um novo sentido para videogames [PT-BR]

André N. Darcie — Thu, 01 May 2025 12:41:58 +0000

Introdução

Em 2013 joguei Gone Home, há mais de dez anos, e ele mudou completamente o que eu achava que um videogame poderia ser. Destruiu minhas crenças. Me obrigou a encarar uma epifania tão bruta e desconfortável que levou mais de uma década para eu começar a digerir.

Jogo

Quando penso em "jogo" no sentido mais puro e essencial, fora do digital, penso em um conjunto claro de regras que definem vencedores e perdedores, como no futebol, vôlei, golfe ou pôquer. O primeiro sucesso digital foi Pong (1972), lançado em 1972 pela Atari: basicamente um "tênis de mesa" virtual, dois jogadores controlam raquetes verticais e devem rebater uma bola em linha reta; deixar passar é ponto para o oponente. Depois vieram níveis, fases, mais desafio e ação com Space Invaders (1978), puzzles com Tetris (1984) e power-ups em Pac-Man (1980). Em Super Mario Bros. (1985), a essência é atravessar plataformas e vencer obstáculos; em The Legend of Zelda (1986), explorar, pegar itens e derrotar inimigos; em Metal Gear Solid (1998), mais cinematográfico, infiltrar-se em bases evitando ser detectado. Em todos esses casos, não importa a história, os gráficos ou a tecnologia: o núcleo sempre foi o mesmo — regras claras, objetivos definidos, ação estruturada em vencer, avançar, sobreviver ou resolver.

Quando comecei Gone Home, achei que fosse um jogo de terror: casa grande, chuva, noite, ambientes escuros, pequenos puzzles. Esperei um susto — nada aconteceu. Controle em primeira pessoa, mas sem voz, inventário, níveis, árvore de habilidades, barra de vida. Só olhos. E do outro lado? Nada. Sem inimigos. Sem puzzles de verdade. Sem correr contra o relógio. Sem armas. Sem habilidades. Você é apenas uma pessoa comum, em uma casa comum e vazia. Não existe aventura. Só exploração livre e reconstrução da história a partir do ambiente, sem diálogos, sem personagens interativos, sem missões.

Influência

Gone Home rasgou o modelo tradicional de "ação e objetivo" e focou 100% em exploração e narrativa ambiental, algo praticamente inexistente na época. Embora Dear Esther já tivesse dado os primeiros passos nesse formato, foi Gone Home que consolidou e popularizou o gênero, provando seu potencial comercial e crítico. Mostrou que jogos podem contar histórias emocionais profundas — sobre família, sexualidade, aceitação — sem combate, sem missão, sem desafio, sem sequer levantar uma arma ou marcar pontos. Foi um dos marcos na criação do que hoje chamam de "walking simulator", influenciando títulos como The Stanley Parable, Firewatch e What Remains of Edith Finch, entre outros. Também quebrou barreiras temáticas, trazendo discussões polêmicas para o centro, de forma madura..

O impacto foi tão grande que muita gente ficou perdida, sem saber se aquilo era mesmo um videogame. "Walking simulator" surgiu como termo pejorativo. E mesmo grandes estúdios, como a Naughty Dog, beberam dessa fonte, adicionando momentos mais contemplativos em Uncharted 4.

Eu cresci jogando videogame. Já sabia o que esperar: vencer, perder, marcar pontos, completar fases. Gone Home veio como um martelo. Destruiu esse conceito até sobrar uma folha em branco. Redefiniu para mim o que é videogame e o que ele pode ser.

isso não é jogo.
isso não é jogo.
isso não é jogo.

Gone Home foi pensado como uma ruptura proposital. Steve Gaynor e a Fullbright queriam uma narrativa íntima e emocional, sem inimigos, sem ação, focada em ambientação, inspirados por Minerva’s Den. O sucesso, somado à polêmica ("isso não é jogo"), consolidou Gone Home como o ponto zero dos walking simulators modernos, abrindo espaço para experiências focadas apenas em história e reflexão.

Não há vitória. Não há derrota. Tampouco um objetivo explícito a ser conquistado. A lógica tradicional do triunfo é abandonada: não se escolhe entre modos Fácil, Médio ou Difícil. Em seu lugar, resta apenas a experiência sensível — sentir, compreender, refletir — como únicos movimentos possíveis dentro da narrativa.

Gone Home foi essencial para a criação do Bitsy, ao mostrar a Adam Le Doux que a exploração de ambientes e a narrativa íntima poderiam ser o coração de uma experiência de jogo. Inspirado por essa abordagem, ele desenvolveu o Bitsy como uma ferramenta voltada para a criação de pequenos mundos e histórias pessoais. Apesar de sua simplicidade e minimalismo, o Bitsy conquistou um espaço de destaque no cenário mundial de desenvolvimento de jogos e, no Itch.io — a maior plataforma de jogos independentes — figura entre as 10 engines mais utilizadas, ao lado de gigantes como Unreal Engine, RPG Maker, Game Maker e Unity.

História

Em Gone Home, você é Katie, uma jovem que retorna para casa depois de um ano viajando e encontra tudo vazio, ecoando ausências. Ao explorar cada canto, você descobre que sua irmã, Sam, viveu um romance secreto com outra garota, enfrentou a rejeição da família e, no fim, fugiu para viver esse amor.

É estranho? Incomum? É cru, vulnerável. Um nível de exposição emocional que nem Hollywood costuma ter coragem de tocar, muito menos os games tradicionais. Aqui não há heróis salvando princesas, cientistas resolvendo catástrofes ou soldados combatendo terroristas. Existe apenas a vida real, com toda sua dor, desejo e imperfeição. É íntimo, é humano. Parece mais uma delicada história francesa, sussurrada, profunda.

O valor das experências

Além da ruptura estrutural, Gone Home também foi alvo de críticas pela sua curta duração. Muitos jogadores questionaram pagar preço cheio por uma experiência que, para a maioria, dura entre uma e duas horas. Isso abriu um debate que se estenderia para outros jogos focados em narrativa: o valor de um jogo deveria ser medido pela quantidade de horas, pela profundidade da experiência, ou por outro critério? A polêmica expôs o quanto a indústria e o público ainda estavam presos à ideia de que tempo de jogo é equivalente a valor.

Comparação com a indústria

Se você olha para as maiores franquias — Mario, Tetris, Call of Duty, Pokémon, GTA, Minecraft, FIFA — todas giram em torno da mesma base: regras claras, objetivos definidos, recompensa constante. Jogar para vencer. Jogar para progredir. Mesmo Minecraft, lembrado pelo modo criativo, ganha peso real no modo sobrevivência: construir, evoluir, proteger-se de monstros, resistir noite após noite.

Num mundo onde Call of Duty é gigante e Counter-Strike movimenta milhões de jogadores na Steam, imaginar um jogo pacífico, explorativo, onde nem a sua história é vivida — apenas se descobre a história dos outros, lendo papéis e diários abandonados — soa quase absurdo. Não há herói. Só um observador.

Myst (1993) construiu um mundo sem textos ou inimigos, focado em exploração e resolução intensa de puzzles como principal forma de narrativa. System Shock (1994) usou gravações de áudio e cenários destruídos para reconstruir uma catástrofe. Half-Life (1998) eliminou cutscenes e obrigou o jogador a presenciar os eventos dentro do próprio cenário. Deus Ex (2000) espalhou fragmentos de história em documentos, diálogos e espaços físicos, ligando narrativa a exploração e escolhas. BioShock (2007) transformou Rapture numa cidade-personagem, onde cada ruína, cada grafite e cada gravação reforçavam a falência de uma utopia. Dark Souls (2011) escondeu todo seu enredo em fragmentos do mundo e nas descrições de itens, exigindo do jogador leitura ativa do ambiente. Mas quase todos ainda dependiam de combate, vitória, progressão — até que Gone Home (2013) rompeu totalmente: nada de combate ou mecânicas profundas de gameplay. Só narrativa ambiental pura.

Todos esses jogos são fantásticos e têm seus méritos. Mas Gone Home rompeu com tudo isso — e provou que, sim, existe espaço para algo realmente diferente.

Conclusão

Gone Home não foi só um jogo, foi um manifesto silencioso que desafiou os alicerces da indústria ao trocar ação por introspecção, desafio por contemplação, e vitória por empatia; ao abandonar as regras tradicionais que definem um jogo, ele não apenas abriu caminho para um novo gênero, mas escancarou a possibilidade de que experiências interativas podem ser também íntimas, humanas e profundamente emocionais — sem precisar das mecânicas e gameplay tradicional.

Profundos agradecimentos aos meus amigos que ajudaram a revisar o texto e a melhorá-lo de forma espetacular: Adriel, Danilo, Diguifi, Drão, Geovani e Jean — listados aqui em ordem alfabética.