Essa é a minha tese, e eu sei que ela é impopular. Levei dez anos de paciência pra poder escrever esse texto. Fiquei calado vendo esse teatro se repetir ano após ano, esperando o momento certo de documentar tudo o que testemunhei de perto, e hoje eu posso, com prazer, ver minhas próprias previsões se confirmando uma por uma.

E antes que algum espertinho tente essa: eu sei que boicote, doxxing e caça às bruxas existem sem CODE_OF_CONDUCT.md nenhum, sempre existiram. O título mira no que esse arquivo virou: o instrumento que pegou uma tática de turba de internet e carimbou ela como política oficial do projeto, com comitê, processo e verniz de legitimidade institucional. Um arquivo markdown de 500 linhas não assusta ninguém sozinho; o que ele virou, sim.

Dinheiro fácil foi o combustível. Código de conduta foi a arma que essa gente construiu pra oficializar o que antes era só grito de rua.

Uma pergunta é de onde veio a energia; outra é o instrumento que ela adotou pra virar poder permanente dentro do projeto. Guarda essa distinção, porque ela sustenta o texto inteiro. Mas antes de chegar na filosofia, deixa eu contar a parte econômica, porque sem entender o dinheiro você não entende o resto.

A bolha que financiou tudo isso

De mais ou menos 2012 até 2022, a indústria de tech viveu a maior bolha de contratação da história. Juros a zero, capital infinito, e as big techs crescendo como se não houvesse amanhã. Chegamos ao ponto surreal de empresas contratarem engenheiros sem ter trabalho para eles. Keith Rabois, da turma do PayPal, acusou Google e Meta publicamente de contratar milhares de pessoas para fazer “trabalho falso”, por vaidade, e para que não fossem trabalhar nos concorrentes. Uma ex-funcionária da Meta, demitida na primeira leva de 2022, resumiu melhor: “eles estavam estocando a gente como cartas de Pokémon”. A cultura do “rest and vest”, colecionar salário e stock options fazendo quase nada, já era documentada em 2017.

Foi essa bolha que financiou a onda de “programação é a profissão do futuro”. Bootcamps saíram de 2.178 formados em 2013 para quase 25 mil em 2020 só nos EUA e Canadá, crescimento de mais de mil por cento. O Bloomberg resolveu aprender a programar como promessa de ano novo em 2012. O Obama escreveu uma linha de código na TV em 2014.

Eu contei essa história com mais detalhes num vídeo de fevereiro de 2020, quando a bolha ainda estava inflando (transcrição aqui):

Influencer de tech virou profissão. Todo mundo ia ser programador.

Aí a bolha estourou. 2022: quase 165 mil demitidos. 2023: mais de 262 mil, segundo o Layoffs.fyi. Meta cortou 11 mil em novembro de 2022 com o Zuckerberg admitindo “I got this wrong”, e mais 10 mil no “ano da eficiência” de 2023. Amazon cortou 27 mil. Google, 12 mil, com o Pichai admitindo que “contratamos para uma realidade econômica diferente da que enfrentamos hoje”. Stripe foi a mais honesta: “we overhired”.

Eu registrei esse estouro no calor do momento, num vídeo de novembro de 2022 (transcrição aqui):

E como o timing é uma piada pronta, em 30 de novembro de 2022, bem no meio do banho de sangue, saiu o ChatGPT. Cem milhões de usuários em dois meses, o aplicativo de crescimento mais rápido já visto até então, segundo estimativa do UBS. As manchetes viraram uma palestra da ACM chamada “Large Language Models and the End of Programming”, Jensen Huang dizendo que criança nenhuma precisa mais aprender a programar, o Devin se anunciando como o primeiro engenheiro de IA, o Dario Amodei prometendo que IA escreveria 90% do código em três a seis meses. Spoiler: não escreveu.

Por que essa história importa? Porque foi exatamente durante essa década de dinheiro fácil que o open source foi colonizado. Quando sobra dinheiro e falta trabalho real, sobra tempo e gente para fazer política dentro dos projetos. E foi o que aconteceu.

A década da caça às bruxas

O artefato central dessa história é o Contributor Covenant, criado em 2014 por Coraline Ada Ehmke e adotado por milhares de projetos, incluindo praticamente todo gigante do setor: CNCF, Apple, Google, Microsoft, Linux. A própria autora, no dia em que o Linux adotou o código dela, tuitou com todas as letras: “Some people are saying that the Contributor Covenant is a political document, and they’re right”. Quando o autor do documento admite que ele é político, a discussão sobre “espaço seguro” acabou antes de começar.

A lista de vítimas dessa era é longa, então vamos aos principais.

Antes, vale registrar o alcance dessa turma. A Coraline trabalhou no GitHub entre 2016 e 2017, até ser demitida (a versão dela está no texto “Antisocial Coding: My Year at GitHub”). E o GitHub era o alvo perfeito: era onde morava praticamente todo o open source do mundo. Foi nessa era que os fundadores originais saíram de cena. Tom Preston-Werner renunciou em 2014 no escândalo de assédio da Julie Ann Horvath, mesmo com a investigação interna concluindo que não houve nada ilegal, só “erros de julgamento”. O Chris Wanstrath já tinha anunciado que sairia do cargo de CEO em 2017 e, depois da venda para a Microsoft em 2018, ainda ficou alguns anos como technical fellow até sair de vez. Hoje nenhum fundador original trabalha lá.

O legado dela sobreviveu à demissão. O Contributor Covenant virou um dos templates que o GitHub facilita adotar quando você cria o CODE_OF_CONDUCT.md de um repositório. E em 2020 veio a joia da coroa: no meio dos protestos do George Floyd, o GitHub anunciou que ia aposentar o nome master, e desde 1º de outubro de 2020 todo repositório novo nasce main.

A discussão era estúpida desde o começo. O Git nunca teve branch slave. O Petr Baudis, que batizou o nome nos scripts originais, explicou no X que master ali era de “master copy”, como a gravação master de um disco (o próprio Baudis disse depois que hoje prefere main; a etimologia continua a mesma). Nem esse detalhe segurou a mudança: até a Software Freedom Conservancy endossou publicamente a troca, e quem tinha automação assumindo master teve que correr atrás. Ninguém ficou mais protegido por causa dessa mudança, mas ela está lá, no fluxo de trabalho de todo programador, todos os dias.

Brendan Eich, 2014. O cara inventou JavaScript, cofundou a Mozilla, era CTO desde 2005. Virou CEO e durou onze dias no cargo. O crime: uma doação de mil dólares em 2008 para a Proposition 8 da Califórnia. Funcionários tuitaram pedindo a cabeça dele, o OkCupid bloqueou usuários de Firefox com uma mensagem de protesto, e ele caiu. Andrew Sullivan, gay e um dos primeiros defensores de peso do casamento entre pessoas do mesmo sexo, escreveu na época “The Hounding of a Heretic”: quando carreiras dependem de teste de pureza ideológica, a caça às bruxas já venceu. E repara: aqui não tinha código de conduta nenhum envolvido, foi pressão pura de boicote. O método já existia antes do documento; o documento só oficializou.

Larry Garfield, 2017. Doze anos de contribuição no Drupal. Quando vazaram que ele participava de uma subcultura BDSM, num site privado, fora do projeto, o comitê de conduta do Drupal investigou e concluiu: sem violação do código de conduta. O Dries Buytaert passou por cima do próprio comitê e expulsou ele assim mesmo, porque a “associação com o sistema de crenças dele” era incompatível com os objetivos do projeto. O TechCrunch resumiu do mesmo jeito: punido por algo dito fora do projeto. Oitenta e cinco desenvolvedores assinaram carta aberta ameaçando sair. Não adiantou. E repara no detalhe que enterra a tese do “espaço seguro”: o processo do código de conduta funcionou e inocentou o cara. Quando a turba apertou, o papel não segurou nada; quem decidiu foi a pessoa no topo, como sempre foi.

Node.js, 2017. O TSC de treze pessoas votou a expulsão do Rod Vagg por, entre outras coisas, ter twitado um artigo questionando os efeitos colaterais de código de conduta. Ler crítica a código de conduta quase virou violação de código de conduta: a votação foi 6 a 4 contra a expulsão, por pouco. A máquina perdeu essa rodada, mas o recado já tinha saído: quatro dos que queriam o cabeça do Vagg pediram para sair do comitê no mesmo dia, e o projeto ganhou um fork chamado Ayo.js horas depois. Perder a votação não impediu o estrago.

Linus Torvalds, 2018. Em setembro, segundo os relatos da época, a New Yorker tinha mandado perguntas sobre o comportamento abusivo dele nos emails. No mesmo fim de semana, Linus pediu desculpas e anunciou que ia tirar um tempo para “entender as emoções das pessoas” e o kernel trocou o Code of Conflict pelo Contributor Covenant. O Linus é grosseiro nos emails desde sempre, todo mundo sabe, e ele voltou um mês depois. Mas o recado foi dado: se nem o cara que criou o kernel estava a salvo, ninguém estava.

Richard Stallman, 2019. O criador da GPL, fundador da FSF, a encarnação do software livre. Vazaram um thread de lista de email do MIT em que ele discutia semântica jurídica sobre o caso Minsky/Epstein. A Vice estampou que ele tinha “defendido Epstein” e chamado as vítimas de “entirely willing”, uma leitura que o próprio thread de emails não sustenta: ele questionava a terminologia jurídica da acusação contra o Minsky. A campanha “Remove Richard Stallman” explodiu, e em dias ele renunciou do MIT e da presidência da FSF. Quando ele voltou ao conselho da FSF em 2021, saiu uma carta aberta com mais de 3 mil assinaturas e dezenas de organizações exigindo a cabeça dele e de todo o conselho. A Red Hat cortou o financiamento da FSF. A carta de apoio juntou quase 7 mil assinaturas e, detalhe delicioso, o Debian votou uma resolução sobre o caso e a opção vencedora foi não se manifestar. Até para fingir neutralidade precisou de votação.

E tem o caso mais recente e talvez o mais didático: Tim Peters, 2024. Lenda do Python, três décadas de contribuição, suspenso por três meses pelo comitê de conduta da PSF por acusações vagas de criar “atmosfera de FUD”, numa briga sobre os estatutos da fundação e sobre os métodos do próprio comitê. A comunidade reagiu feio, mas não teve volta: ele cumpriu os três meses e só voltou quando a suspensão expirou, em novembro. O padrão se manteve: discordar da moderação virou ofensa punível.

DHH, 2021. Deixei esse para o final porque é o caso que muda a história. E note: aqui nem open source era, era a empresa dele. O mesmo mecanismo, agora dentro do escritório. Em abril de 2021, no auge da era BLM, um comitê interno de DEI dentro da Basecamp, a empresa do criador do Ruby on Rails com o Jason Fried, desenterrou uma lista antiga de “nomes engraçados de clientes” que circulava na empresa. A discussão escalou até um funcionário citar a “pirâmide do ódio” e argumentar que aquela lista era o fundamento de violência racial e até genocídio. A resposta dos fundadores foi fechar o assunto, dissolver o comitê e proibir discussão política e social nos canais internos. A internet explodiu. Na reunião geral seguinte, foram duas horas e meia de gente chorando e gritando no Zoom. O Ryan Singer, dezoito anos de casa, disse ali que não aceitava o rótulo de “cultura de supremacia branca” aplicado à empresa. Foi suspenso meia hora depois da reunião e se demitiu no fim de semana. Ao final, um terço da empresa, vinte dos 57 funcionários, saiu com pacote de demissão voluntária.

E é aqui que esse caso se separa de todos os outros: ele não dobrou. Sem ritual público de humilhação, sem pedido de desculpas, sem volta atrás. Preferiu perder um terço da empresa a entregar o controle dela. A Basecamp sobreviveu, virou 37signals de novo, e o DHH aprendeu ali, na carne, com que tipo de gente estava lidando. Guarda esse nome, porque ele volta.

Alguém vai apontar que a regra dele também é um documento escrito proibindo um assunto. É, e a diferença é exatamente o ponto: a regra do DHH bane um tópico inteiro, igual pra todo mundo, não importa o lado. Código de conduta bane pessoa e opinião, seletivamente, dependendo de quem está no poder naquele mês.

Uma trava o assunto na porta. A outra abre um tribunal lá dentro.

Repara no padrão. Em nenhum desses casos o problema era código. Em nenhum deles alguém commitou bug, roubou código, sabotou release. As ofensas foram opiniões, doações políticas, vida privada, semântica em lista de email. O critério técnico foi substituído pelo critério político, e o código de conduta foi o instrumento jurídico dessa substituição. São casos famosos, não estatística. Mas quando a lista inclui os criadores do JavaScript, da GPL e do Linux, a amostra não precisa ser grande para passar o recado.

E os resultados?

Dez anos de era do código de conduta deveriam ter deixado um rastro de números bons. Se a justificativa era proteger minorias e tornar o open source mais diverso e menos tóxico, cadê a melhora? Fui procurar a pesquisa séria sobre o assunto. O que existe conta uma história interessante.

Sobre adoção: Tourani, Adams e Serebrenik mediram em 2017 que cerca de 35% dos 150 projetos mais populares do GitHub tinham código de conduta. E que enforcement era raro: os criadores desses códigos, numa amostra de quatro entrevistados, falavam em casos de um dígito ao longo de anos. Um estudo de 2021 da CSCW olhou 52 mil repositórios: 12,6% tinham CoC, e só 10% das conversas mencionando o código eram uso real dele em moderação. A maioria das adoções aconteceu sem discussão pública visível no repositório. O mesmo paper diz, com todas as letras, que não existe evidência empírica de que código de conduta atraia novos contribuidores.

Sobre atrair gente, aliás, Qiu et al. mediram o que realmente faz alguém entrar num projeto: README bom, número de estrelas, atividade recente, template de issue. Código de conduta nem entrou como variável no modelo deles, e olha que eles testaram maintainer responder rápido, que também não deu significativo. Quem mediu especificamente onde o CoC fica no ranking de fatores foi um estudo separado, o Fronchetti, Wiese, Pinto e Steinmacher, também de 2019: CoC ficou entre os fatores pior colocados pra atrair contribuidor novo. Ninguém escolhe projeto pelo código de conduta.

Sobre diversidade, que era a promessa original, tem estudo específico e a resposta é não. O Robson, no ESEC/FSE de 2018, olhou os 500 projetos mais populares do GitHub: projetos que adotaram CoC viram a participação de mulheres crescer praticamente no mesmo ritmo dos que não adotaram (por volta de 1,44% de aumento contra 1,43%, segundo o levantamento posterior que cita o estudo). Sem diferença estatística que sustente a promessa. O Enache, em dissertação de mestrado de 2017 pra TU Eindhoven, sobre 149 comunidades open source, chegou na mesma conclusão: nenhum resultado significativo de que CoC mude a participação de mulheres.

E tem uma pesquisa nova, de peso, publicada agora em 2026 no ICSE, a conferência mais importante da área: o Sun et al. rodou um experimento causal de verdade, comparando 4.684 pares de repositórios que adotaram CoC contra pares equivalentes que não adotaram. O resultado tem duas pontas. Adotar CoC atrai sim mais contribuidor novo, e esse efeito cresce com o tempo. Só que adotar CoC também aumenta o número de contribuidores antigos que se desengajam, efeito concentrado justamente nos primeiros um a três meses depois da adoção. Ou seja: o próprio estudo mais recente e mais rigoroso que existe mostra, com número, o padrão que esse texto documentou caso por caso o tempo todo. Adotar o documento não constrói comunidade nova, ele expulsa gente que já estava lá.

O levantamento do GitHub de 2017 já marcava 95% homens e 3% mulheres no open source. O melhor dado de longo prazo que existe, do Rossi e Zacchiroli no ICSE 2022, analisou 2,2 bilhões de commits do arquivo do Software Heritage. Gênero detectável para 64% dos autores e, nesse grupo, mulheres são 13,5% dos autores e assinam 8,1% dos commits. A participação delas vinha crescendo devagar e de forma contínua havia doze anos, e caiu na pandemia. O paper não fala de código de conduta, então a leitura que segue é minha, não do estudo: uma curva que sobe do mesmo jeito a década inteira, sem nenhum degrau visível quando o Contributor Covenant se espalhou, é o oposto de evidência de que o documento fez diferença.

Sobre toxicidade, o estudo da ICSE 2022 acha, em nota de rodapé e por extrapolação, algo perto de 1,3 comentários tóxicos por mil no GitHub. Ninguém tem uma série histórica comparando antes e depois da era CoC. Simplesmente não existe baseline pra dizer se piorou ou melhorou.

O único experimento randomizado que sustentaria a tese das regras é do Matias, publicado na PNAS em 2019: lembretes de regras exibidos ativamente numa amostra sorteada de threads no r/science aumentaram em 70% a participação de novatos. Só que o experimento é no Reddit, com a regra pregada bem na cara de quem entrava naquela thread específica. Um arquivo estático esquecido no repositório, que ninguém lê depois do dia da adoção, não chega nem perto disso. A própria pesquisa que mostra uma regra funcionando é a prova de que o problema nunca foi ter ou não ter o arquivo. É ninguém aplicar, ninguém mostrar, ninguém fazer valer.

Resumindo: uma década inteira de códigos de conduta, e a promessa original continua exatamente isso, uma promessa. O que ficou documentado foi adoção sem discussão, enforcement raro e, no máximo, um monte de processo político.

Como proteção, quase nunca é invocado. Como arma política, só precisa ser invocado uma vez, contra a pessoa certa.

A contra-reação veio de onde ninguém esperava

O dinheiro fácil acabou em 2022 e, com ele, a paciência da indústria para esse teatro. E a liderança da reação foi o cara que já tinha se recusado a dobrar em 2021: o DHH, ex-fanboy de Mac da velha guarda.

O DHH vem escrevendo contra essa onda faz tempo: “The waning days of DEI’s dominance” em 2022, “DEI is done” em 2024. Em 2022 a Ruby Central tirou ele do keynote da RailsConf, a conferência do framework que ele mesmo criou, dizendo que queria “dividir o palco de abertura com outros contribuidores”. No ano seguinte nasceu a Rails World, a conferência oficial da Rails Foundation, e o DHH virou keynote dela. Em 2024 lançou o Omakub e, em junho de 2025, o Omarchy: Arch Linux com Hyprland e um monte de scripts opinativos em cima, que passava de 40 mil stars no GitHub em setembro de 2026 e virou o ambiente padrão da 37signals pra quem mexe com infra e Ruby.

Aí a máquina de cancelar ligou de novo. Em setembro de 2025 ele publicou “As I remember London”, e a reação foi o script de sempre: petição para tirá-lo, acusações, tentativa de boicote. A resposta dele foi “We’ve all had enough of this nonsense”: “a cada poucos anos, o mesmo grupelho triste de descontentes do Ruby tenta me cancelar do Rails”.

Um mês depois, em outubro de 2025, foi a vez da Framework, fabricante de laptops: um thread com mais de 1.500 respostas no fórum da própria empresa, aberto por um desenvolvedor Debian chamando a comunidade do Hyprland, que a Framework patrocinava, de “tóxica e odiosa”, e ameaçando boicote porque a empresa também promovia o Omarchy nas redes. A resposta do CEO da Framework é a frase que faltava nessa década inteira:

“Criamos deliberadamente uma barraca grande, porque queremos que o open source vença. Não fazemos parceria com base nas crenças de indivíduos ou organizações.” (“big tent”, no original.)

E a máquina não bateu só nele. A Ruby Central, a mesma que tinha desconvidado o DHH do keynote em 2022, deu palco para ele na RailsConf 2025. A retaliação veio em dinheiro: segundo a apuração do desenvolvedor Joel Drapper, a Sidekiq retirou o patrocínio de 250 mil dólares por ano por causa disso. Semanas depois, em setembro de 2025, a Ruby Central removeu do GitHub todos os maintainers de longa data do RubyGems e do Bundler, alegando segurança da cadeia de suprimentos. A Ellen Dash, que mantinha o projeto havia dez anos, pediu conta chamando o movimento de “hostile takeover”, e a investigação do Drapper aponta pressão da Shopify, que tinha virado praticamente a única fonte de dinheiro da organização. A própria Ruby Central acabou publicando um relatório do incidente em abril de 2026, prometendo “fortalecer a governança”. Esse é o padrão completo: quando a máquina não derruba o alvo, incendeia a casa em volta dele.

Um desenvolvedor do GNOME publicou um texto atacando o Omarchy no blog oficial de blogs do GNOME. E o resultado de toda essa fúria? Nada. Em agosto de 2026 nasceu a Omacom Foundation, com oito milhões de dólares no lançamento: um milhão de cada um de Tobi Lütke (Shopify), Patrick Collison (Stripe), Michael Dell, Jack Dorsey, Matthew Prince (Cloudflare), Brendan Iribe, Jason Fried e o próprio DHH. A fundação virou patrocinadora exclusiva do Hyprland, com o Vaxry trabalhando em tempo integral. Quando a 1Password entrou como patrocinadora, a tentativa de cancelamento foi imediata e a resposta interna do CEO também: “nossa doação não é endosso de opiniões pessoais”. E segue o jogo.

E eu botei o meu dinheiro onde está a minha boca: fiz a minha doação para a fundação exatamente por causa do chororo da patrulha. Nada irrita mais essa turma do que ver o cancelamento falhar em tempo real.

Esse é o ponto: a máquina ainda existe, mas perdeu o poder. Em 2014 derrubou um CEO em onze dias. Em 2026 não consegue arranhar um patrocínio de distro de nicho. Os documentos continuam lá, no template do GitHub; o que acabou foi o poder de fogo de quem os empunhava. O que mudou foi o dinheiro, e sim, a contra-reação também é dinheiro: oito milhões de dólares de oito homens ricos.

E antes que alguém aponte que dinheiro não prova mérito: depende. Milionário criado por conchavo de governo, fraude ou favor não tem mérito nenhum. Mas a maioria dos milionários se fez produzindo, e é o caso dos oito patronos da Omacom. Dinheiro ganho produzindo é a medida do mérito de quem o fez, como eu já escrevi aqui em 2011, sobre o discurso do dinheiro do Francisco D’Anconia em “A Revolta de Atlas”.

Julgue pelo resultado que a doação comprou, não pela intenção declarada de quem assina o cheque.

Os 49,5 bilhões de dólares corporativos de 2020 não produziram um grama a mais de diversidade mensurável, os números aí em cima provam isso. Oito milhões de dólares de patrono individual produziram um maintainer em tempo integral escrevendo código de verdade. A bolha que financiava exércitos de gente sem trabalho real estourou, e quem sobrou foi quem estava lá pelo código.

A parte filosófica

Vamos à desculpa oficial: códigos de conduta existem para “proteger minorias”. Na superfície, quem seria contra proteger minorias? Eu não sou. O problema é que a frase é vaga por design.

O que é uma minoria? Eu já traduzi aqui no blog o capítulo “Direitos do Homem” de “The Virtue of Selfishness”, da Ayn Rand. A frase que me interessa aqui está em outro capítulo do mesmo livro, “Racism”, e continua imbatível:

A menor minoria da Terra é o indivíduo. Quem nega direitos individuais não pode dizer que defende minorias.

E é exatamente isso que esses códigos fazem na prática: em nome de uma minoria abstrata e coletiva, persegue-se o indivíduo concreto. Doxxing (expor os dados pessoais da pessoa), campanha de assédio, pressão no empregador, banimento. Quando o modus operandi para “proteger minorias” é bullying coordenado contra uma pessoa até ela dobrar os joelhos, você está oprimindo a menor minoria que existe.

Esse assunto, aliás, é velho para mim. Em dezembro de 2018 eu publiquei no meu canal o vídeo “Manifesto Anti-Parasita: Seja um Criador”. Na época eu não podia ser explícito, a polícia do pensamento ainda estava forte demais. Mas quem assistiu com atenção entendeu o recado. Era o meu breadcrumb para essa história que eu só estou podendo contar direito agora.

E tem o segundo problema, mais fundamental: open source é sobre software. A GPL, que essa turma tanto despreza, resolve a proteção que um projeto de software não pode perder: a do código. Garante que o código continue livre, ponto. Ela não pergunta quem escreveu, em quem votou, o que tuitou, o que doou. O compilador não checa pureza ideológica. O open source sempre foi a comunidade mais inclusiva que já existiu justamente por isso: o único passaporte era o diff. O código de conduta tornou o open source menos inclusivo, porque adicionou um critério novo à entrada: política. E política é um critério estúpido para software.

“Ah, mas sem código de conduta, como lidamos com assédio real?” Com a mesma ferramenta de sempre: bom senso de maintainer e, quando necessário, a lei. Se alguém ataca outra pessoa diretamente, uma agressão sexual num evento, por exemplo, banir é senso comum e nunca precisou de documento nenhum. Assédio, ameaça e difamação já são crimes em praticamente todo país, e crime se resolve no caminho da lei. O que eu não engulo é outra coisa: sair stalkeando a vida online de alguém para desenterrar uma opinião aleatória, sem relação com crime nenhum, e exigir banimento por causa de palavras sem consequência criminal. Esses comitês sempre foram ótimos em punir opinião e péssimos em punir crime, então o documento nunca foi sobre isso.

E não sou eu sozinho dizendo isso. Eric S. Raymond, o cara que escreveu “The Cathedral and the Bazaar”, o texto de 1997 que validou pra Netscape a decisão de abrir o código do Mozilla e que praticamente escreveu as regras do jogo do open source, cofundador da OSI, editor do Jargon File, autor do fetchmail, foi ao X em setembro de 2025 declarar a era dos códigos de conduta um fracasso completo. Nas palavras dele: dez anos de “drama e idiotice”, uma “insanidade social infecciosa” que produz política, intriga e trabalho útil negativo. A recomendação é a mais direta possível: não adote; se já adotou, delete. E se alguma burocracia te obrigar a ter um, a substituição sugerida tem uma frase só:

“Se você é mais chato de trabalhar do que as suas contribuições justificam, você é ejetado.”

É o que eu disse dois parágrafos acima: bom senso de maintainer.

E o detalhe que fecha o círculo: o próprio ESR tinha sido removido de duas listas de email da OSI em 2020 por posts que “violaram o código de conduta” da organização que ele ajudou a fundar.

O cara que escreveu as regras do jogo, ejetado pelo documento. Essa imagem resume a era inteira.

Como chegamos até aqui

Vale dar um passo atrás e contar de onde veio tudo isso, porque o open source foi só um dos fronts. O tiro de largada, na minha leitura, foi o GamerGate, em 2014. Em agosto daquele ano saiu o “Zoe Post”, o desabafo do ex-namorado da desenvolvedora Zoe Quinn. Doze dias depois, e cerca de 48 horas depois de a hashtag #GamerGate pegar força, cerca de uma dúzia de sites de games publicou variações do mesmo artigo: “gamers are over”, os jogadores estão mortos, acabou.

Pouco depois vazou o GameJournoPros, um grupo fechado onde jornalistas de games coordenavam cobertura. O público percebeu na hora que a imprensa de games tinha virado clube ideológico, e reagiu com a própria versão do boicote organizado: a campanha “Operation Disrespectful Nod” inundou a Intel de reclamação até a empresa tirar os anúncios da Gamasutra (a imprensa da época chamou de “campanha anti-feminista”; pra mim é só pressão organizada de consumidor, o mesmo instrumento que a Sidekiq usou contra a Ruby Central lá na frente).

E aqui vale fixar o princípio, porque ele vale pros dois lados o resto do texto inteiro: pressão organizada de consumidor é jogo limpo, não importa de que lado vem. O problema nunca foi pressão. É doxxing, ameaça de emprego e comitê fingindo neutralidade pra impor o resultado que já queria antes de abrir o processo.

Durante anos, de 2021 a junho de 2025, o artigo da Wikipedia sobre o assunto viveu batizado “Gamergate (harassment campaign)”, tratando qualquer crítica ao jornalismo como pretexto de assédio. O título foi trocado de volta pra simplesmente “Gamergate” depois que a fase mais histérica passou, o que devia ser lido como uma confissão, não como se o caso estivesse encerrado: renomearam de volta quando ficou caro demais defender o rótulo político, exatamente o mesmo padrão de recuo silencioso que aparece em toda essa história. Enquanto durou, durou justamente na década em que essa turba tinha poder de fogo pra fazer valer.

A briga editorial foi tão feia que o comitê de arbitragem da Wikipedia puniu mais de uma dúzia de editores, dos dois lados. E olha que eu nem preciso acusar a Wikipedia sozinho: o Larry Sanger, cofundador da Wikipedia, escreveu em 2020 o texto “Wikipedia Is Badly Biased” declarando que a neutralidade do projeto morreu, e em setembro de 2025 publicou as “Nine Theses on Wikipedia”, pedindo reformas como o fim das listas negras de fontes e o fim do bloqueio eterno de editores. Quando o fundador diz que a casa foi tomada, acredite no fundador.

A versão do lado dos gamers dessa história está no livro “SJWs Always Lie”, do Vox Day, de 2015. Já sei o que vem: “Vox Day” e “Milo Yiannopoulos” (espero ter escrito certo) são nomes que fazem gente gritar só de ouvir, e o GameJournoPros, aliás, também foi destrinchado originalmente por esse Milo. Não me interessa a reputação de quem conta a história, me interessa se a história é verdadeira. Fonte partidária de dentro da briga, aviso dado, mas o fato central bate com o que a própria Wikipedia e a imprensa da época documentam sem ligação nenhuma com esses dois nomes: a lista GameJournoPros existiu de verdade, um grupo fechado de umas 150 pessoas do jornalismo de games trocando ideia sobre como cobrir o caso.

O capítulo “Counterattack” conta o GamerGate de dentro, e a tese do livro resume a década: essa gente sempre mente, sempre dobra a aposta, sempre projeta nos outros exatamente o que ela mesma faz.

Do GamerGate em diante, foi dominó. A Anita Sarkeesian transformou o Kickstarter dela de meta de 6 mil dólares em 158 mil, virou autoridade global, foi falar na ONU em 2015 sobre “violência cibernética”, e o jornalismo de games nunca mais se recuperou. O Feminist Frequency dela fechou as portas em 2023, mas a lógica que ela inaugurou migrou para dentro dos estúdios: nasceu a indústria da consultoria de “narrativa inclusiva”, com a Sweet Baby Inc na dianteira.

A CEO da Sweet Baby, Kim Belair, foi gravada numa palestra da GDC de 2019, gravação pública que circula fora do site que primeiro a levantou, aconselhando quem quer aprovação interna pra consultoria de “representação” a “ir tomar um café com o time de marketing e aterrorizar eles” com a possibilidade do que aconteceria se não desse a eles o que queriam. Em 2024, um brasileiro criou no Steam uma página de curadoria (o recurso da própria Valve onde qualquer conta pode publicar recomendações de jogos e ganhar seguidores) batizada de “Sweet Baby Inc Detected”. Um funcionário da empresa tentou individualmente derrubar o perfil por conta própria, e a Valve também agiu por moderação própria; mesmo assim, o resultado foi o grupo explodindo para mais de 350 mil seguidores.

E vieram os flops. O Suicide Squad: Kill the Justice League, com consultoria confirmada da Sweet Baby, custou 200 milhões de dólares de prejuízo à Warner. O Unknown 9, do estúdio onde a dupla fundadora da Sweet Baby trabalhava, demitiu em massa um mês depois do lançamento.

Aí veio 2020. Com o BLM, a mesma cartilha virou política de Estado: as 50 maiores empresas americanas prometeram 49,5 bilhões de dólares em ações de “justiça racial”, vagas de DEI cresceram 123% em meses, Biden assinou no primeiro dia de mandato a ordem executiva de “equidade” para todo o governo federal, e a União Europeia saiu com seu plano anti-racismo 2020-2025. Era o auge: a patrulha tinha chegado à presidência dos EUA e à liderança da UE.

O recuo veio tão rápido quanto a subida. A Suprema Corte americana derrubou o affirmative action em junho de 2023, as empresas demitiram milhares de profissionais de DEI, Walmart, Meta, McDonald’s e Amazon abandonaram os programas, e em janeiro de 2025 o Trump revogou as ordens de equidade no primeiro dia.

Contei tudo isso só para situar: o que aconteceu no open source não foi um fenômeno isolado. Foi o mesmo roteiro, com os mesmos métodos, em todas as indústrias de cultura e tecnologia ao mesmo tempo. A diferença é que no open source a resistência demorou mais para organizar. Mas organizou.

O meu Cortlandt

Foi essa pressão que me tirou da organização da RubyConf Brasil. Eu fundei o evento em 2008, ainda como Rails Summit, e na última edição que eu organizei, em 2016, levamos 1.500 pessoas. Quando anunciei a minha saída, escrevi que não tinha drama nenhum envolvido. Não era a verdade inteira: a patrulha já tinha chegado nas conferências de tecnologia, e eu me recusei a transformar o evento que eu criei em mais um palco dela.

Vou dar um exemplo pequeno do que significa ser obrigado a forçar diversidade. Como os dados que eu mostrei acima indicam, mulheres são de 3% a pouco mais de 13% dos contribuidores de open source, dependendo de como se mede: survey autodeclarado ou detecção por nome nos commits. Os analytics do meu canal mostram a mesma faixa, 3 a 5% no máximo, e essa proporção não mudou em dez anos. Todo ano eu abria um Call for Papers público: qualquer pessoa podia submeter uma palestra. E o meu processo de seleção sempre foi cego: eu lia cada submissão sem saber quem tinha enviado, de propósito, para a escolha ser pelo mérito do tema e nunca pela pessoa.

Nos anos da patrulha, a cobrança nunca foi direta comigo. Era aquela pressão externa e difusa de que todo evento tinha que ser “mais diverso”. E na prática isso só podia significar uma coisa: uma fase nova no processo. Depois da seleção cega, revelar quem tinha submetido o quê, para conferir se o lineup estava “diverso o suficiente”. Só que isso é uma impossibilidade matemática. As submissões seguiam os mesmos 3 a 5%. Mesmo aprovando todas as mulheres que submetiam, a cota imaginária não fechava. O jeito era sair convidando pessoas diretamente, escolhendo pelo perfil, e não pelo tema.

E o resultado prático desse esquema, onde quer que ele seja aplicado, é cortar gente que entrou por mérito para abrir vaga para gente escolhida por uma política externa irrelevante. Isso derruba a qualidade do evento em vez de subir. E repara: isso não é um argumento contra mulher nenhuma. É o contrário. No momento em que a cota entra no processo, a dúvida deixa de ser sobre uma palestrante específica e passa a pairar sobre todo mundo que pisa no palco. Não importa quem esteja falando: se alguém na plateia discordar do conteúdo, sempre vai sobrar a pergunta “será que o Akita escolheu esse por cota?”. A partir daí, todo palestrante carrega uma suspeita que não merece e o mérito de cada um fica desvalorizado por tabela. Prejudica a minoria que a política dizia proteger, prejudica os outros palestrantes, prejudica o público. É lose-lose em todas as pontas.

E tem uma parte dessa história que ninguém vê de fora. Algumas das pessoas convidadas desse jeito recusaram na hora, “porque o evento não era diverso o suficiente”. A recusa deixava o evento menos diverso ainda, óbvio. E depois iam para as redes sociais falar mal do evento, como se eu nunca tivesse convidado ninguém. Esse era o nível do lixo que eu tinha que engolir todo ano.

E que fique bem claro: não existe nada que eu queira mais do que ver mais mulheres na tecnologia. O que eu não consigo me convencer é de que forçar cota, do jeito que eu descrevi acima, ajuda nisso. Tudo que eu vi na prática aponta o contrário: prejudica mais do que ajuda. E se eu não acredito que é benéfico, eu prefiro não fazer.

Quer um exemplo recente de mulher que eu admiro na indústria? Asha Sharma, que assumiu como CEO do Xbox em fevereiro. Desde então é resultado atrás de resultado: cortou o Copilot dos consoles e reestruturou a divisão para focar no que importa, vendeu estúdios e cortou custo sem cancelar nenhum jogo anunciado, e essa semana trouxeram a Kojima Productions para o Xbox publicar o próximo jogo do Hideo Kojima, depois da PlayStation cancelar o projeto em meados de 2026. Repara no discurso em volta dela: zero menção a “gênero”, zero pauta.

Só número: cortar custo desnecessário, apostar nas bets certas, melhorar o valor para o cliente. Isso é mérito. Não precisa de DEI para isso.

Até que eu decidi que chega. Quem leu “The Fountainhead” sabe o que eu fiz: como o Howard Roark, o arquiteto que explode o próprio prédio quando adulteram o projeto dele, eu dinamitei o meu Cortlandt. Mais precisamente: o evento como ele existia enquanto era meu. A marca sobreviveu alguns anos na mão de outros, sem a mesma alma, até desaparecer. E eu já tinha sinalizado essa filosofia aqui no blog ainda em 2011. Um indivíduo não faz nada pelos outros: faz por si mesmo. Se o que você constrói beneficia outras pessoas como efeito colateral, melhor, mas esse nunca foi o motivo. Quando os parasitas querem tomar o que você construiu, você mesmo explode tudo. Porque pode. Quem construiu uma vez, constrói de novo do zero.

Foi o que eu fiz. Troquei a conferência pelo meu canal do YouTube, que não dependia de patrocinador, de comitê, de ninguém além de mim. E o canal cresceu muito além do que a conferência jamais seria. Depois eu sentei e esperei a bolha estourar, porque eu sabia que ela ia estourar: escrevi isso aqui no blog e repeti nos vídeos anos antes de acontecer. Estourou. Paciência sempre vence.

Conclusão

Dez anos de código de conduta e o placar é esse: zero evidência de que aumentou diversidade, nem baseline de toxicidade pra comparar antes e depois, e o estudo causal mais recente e mais rigoroso que existe mostra o documento afastando contribuidor antigo mais do que constrói comunidade nova. A promessa era proteger minorias. A entrega foi uma coleção de cabeças: o criador do JavaScript, o criador da GPL, o criador do Linux, todos passando pelo ritual público de humilhação. Nenhum por causa de código. Todos por causa de opinião.

E repara como essa era terminou.

A máquina não perdeu o debate, perdeu o financiamento.

Foi só o dinheiro fácil acabar que os exércitos de gente sem trabalho real evaporaram, e quem sobrou foi quem estava lá pelo código. Enquanto isso, os builders seguiram construindo: o Brendan Eich foi expulso da Mozilla em 2014 e no ano seguinte fundou a Brave, hoje com mais de 100 milhões de usuários ativos por mês e valuation perto de 1 bilhão de dólares. O DHH perdeu o keynote e criou uma conferência maior, perdeu um terço da empresa e ajudou a levantar uma fundação de oito milhões. Eu saí da minha conferência e cresci muito mais no canal. Instituição, parasita toma. Capacidade de construir, não. Quem construiu uma vez, constrói de novo do zero.

Open source recruta voluntários que querem contribuir código. Qualquer discussão que não envolve código é distração na melhor hipótese e sabotagem na pior. E a resposta para “o que colocar no lugar do código de conduta” cabe numa frase só, que o ESR já escreveu: se você é mais chato de trabalhar do que as suas contribuições justificam, você é ejetado. Sempre foi assim que funcionou. O único passaporte é o diff.

O resto é politicagem. E politicagem, para usar o termo técnico preciso, é bullshit.

E fica a recomendação prática final. Se o seu projeto open source tem um CODE_OF_CONDUCT.md, delete o arquivo. Se o seu branch principal virou main na onda de 2020, renomeie de volta para master. Em parte de birra, admito. Mas principalmente para exercitar a liberdade recém-recuperada de fazer isso sem ser cancelado por causa disso. Liberdade que não se exercita atrofia. Sem nota de esclarecimento, sem votação de comitê, sem pedir licença para ninguém. Só porque agora você pode de novo.

Quatro dias atrás, 5 de abril de 2026, meu blog completou 20 anos. Eu sei, eu atrasei o post comemorativo. Mas tem um motivo, e esse motivo é o assunto desse texto.

Eu comecei em 2006 no Blogspot do Google, como a maioria fazia na época. Depois migrei pra um CMS em Rails 2.0 que já existia, passei pelo Typo3, e lá em 2012 fiz minha própria engine do zero em ActiveAdmin, que fui arrastando de Rails 3 até Rails 7. Só recentemente, em setembro de 2025, finalmente larguei essa engine própria e fui pro Hugo com o tema Hextra, que é onde esse post está rodando agora. Vinte anos carregando os mesmos posts de Textile, migrando de Less pra Sass, trocando Liquid por Markdown, e removendo lixo obsoleto ao longo do caminho.

Duas décadas, cinco eras

Uma coisa que poucos programadores param pra refletir é o quanto o mundo de tecnologia muda em 20 anos. Eu já falei sobre isso no Akitando #37 - A Dimensão do Tempo. Quando eu abri esse blog em abril de 2006, eu já tinha 10 anos de experiência. Já tinha visto a bolha da internet subir e explodir em 2000. E desde então ainda vi mais umas quantas: a ascensão das redes sociais (Orkut, Facebook, Twitter), a revolução do smartphone e do app móvel em 2008, a crise econômica de 2008, o nascimento do Bitcoin em 2009, a era da nuvem e do SaaS, agora a era da IA generativa.

Eu vi essas ondas estourarem na prática. Cada uma delas mudou completamente como a gente trabalha e quem sobrevive profissionalmente. Esse tipo de coisa a gente só enxerga olhando de longe, depois de acumular umas quantas viradas.

Minha carreira em si passou por viradas drásticas. Contei em detalhe nos Primeiros 5 Anos (1990-1995), mas resumindo: comecei em agências de multimídia, migrei pra consultoria enterprise trabalhando com SAP, abandonei tudo em 2006 pra entrar em Ruby on Rails e open source, passei uma década organizando evento, principalmente a Rubyconf Brasil de 2007 até 2018, depois fechei a porta do evento e comecei o canal Akitando no YouTube, que cresceu pra mais de 500 mil inscritos. No meio disso teve a pandemia que reorganizou a vida de todo mundo. E agora, desde o começo de 2025, virei pesquisador e usuário em tempo integral de IA, rodando modelos localmente e quebrando coisas com Claude Code até elas funcionarem.

Olhando pra tag /tags/ai, eu escrevi 51 posts relacionados a IA só entre 2025 e 2026 — 19 em 2025 e mais 32 em 2026, que mal começou. Antes de 2025, entre 2018 e 2024, o blog basicamente virou o arquivo dos transcripts dos vídeos do Akitando. Eu filmava o vídeo, fazia o transcript, jogava no blog, e as pessoas liam lá. Mas desde que eu voltei a escrever ativamente, notei que tinha uma audiência leal que nunca foi embora, mesmo nos anos quietos. E foi esse feedback que me fez começar The M.Akita Chronicles, uma série mais pessoal contando os bastidores de projetos recentes.

O problema que eu nunca resolvi

Durante esses 20 anos, uma coisa me incomodava. Como o conteúdo é todo em português, fica inacessível pra todo mundo que não lê a língua. E faz uns bons anos que eu venho recebendo mensagens de leitores brasileiros morando fora (Portugal, Estados Unidos, Japão, Alemanha, Canadá) pedindo alguma versão em inglês pra compartilhar com colegas gringos. Coisa tipo “olha, eu mostraria esse texto pro meu time, mas só tá em português.”

Eu sempre disse “um dia eu traduzo.” E nunca traduzi. Por quê? Porque são centenas de posts. Passei os últimos dois dias olhando os números: 727 arquivos index.md em português no repositório. Traduzir tudo à mão, um por um, ia tomar semanas se não meses de trabalho dedicado. Eu nunca ia ter fôlego pra isso. E a cada ano que passava, mais posts se acumulavam pra traduzir.

A ironia é que alguns posts do blog nasceram em inglês. Durante 2017 e 2018 eu tinha decidido escrever primeiro em inglês pra tentar alcançar audiência internacional. Uma série inteira de entrevistas, as “chatting-with” com gente tipo Hal Fulton, Scott Hanselman, Chris Wanstrath (do GitHub), Blaine Cook (ex-Twitter), Adam Jacob (Chef), nasceram em inglês e ficaram lá. Faltava o inverso: pegar os posts em português e traduzir pro outro lado.

O fim de semana que consertou 20 anos de dívida técnica

Na segunda passada eu abri o Claude Code dentro do diretório do blog. E pedi pra ele traduzir tudo pra inglês. Foi literalmente isso.

Começou na segunda-feira, dia 6 de abril, por volta das 18:30h. Eu deixei rodar. Fui dormir. Acordei terça, continuei rodando. Dormi de novo. Quarta de manhã cedo ele terminou. Contando o tempo total do primeiro commit de tradução até o último, foi algo como 39 horas. Mas não foi contínuo, teve noites, almoços, uma roda de café. Na prática, um fim de semana estendido de trabalho.

O resultado tá no repositório git, em commits que qualquer um pode inspecionar no repositório público do blog. Olhando rapidamente o log, dá pra ver a cadência: lote de posts de 2008 QCon. Lote de 2009 RailsConf. Lote de 2011 Objective-C. 2012 completo. 2015 série Elixir. 2016, 2017, 2018 completos. Lote depois de lote, organizados por ano e por série. Mais de 80 commits marcados como i18n: ou EN translation: entre o começo da noite do dia 6 e a manhã do dia 8. No final desse post, abri 354 arquivos index.en.md contra os 727 index.md originais. Quase metade do blog inteiro traduzido de um só golpe.

E olha, noventa por cento foi tranquilo. A tradução ficou boa, natural, fiel à minha voz no original — eu não imaginava que ia funcionar tão bem. Claude Code respeita o tom do texto se você der instruções boas de voz e estilo, e mostra respeito por ideias técnicas sem “corrigir” nada do que você escreveu. No pior caso, revisa alguns parágrafos. No melhor caso, a versão em inglês soa como se você tivesse escrito direto na outra língua.

Um parênteses sobre o custo do lado Claude. Eu sou assinante do plano Max 20x da Anthropic, que é o tier de uso pesado feito pra quem abusa do Claude Code o dia inteiro. Nunca tinha batido no teto dele antes, nem nas minhas sessões mais intensas de vibe coding. Esse fim de semana de tradução foi a primeira vez que eu realmente estourei o limite do Max 20x e continuei usando já no modo de “uso extra” (a Anthropic cobra por consumo acima do teto do plano mensal).

Pra ter uma ideia do estrago, esse é o painel da minha conta agora de manhã:

91% da quota semanal “all models” consumida, já pra dentro do modo de uso extra, R$280,88 (uns $50 USD) gastos em cima da mensalidade fixa, e ainda falta um bom pedaço do ciclo. Faz sentido: ler o post inteiro, gerar a tradução, aplicar o humanizer em cima, repetir centenas de vezes seguidas. A quantidade de tokens envolvida é massiva. E hoje, enquanto eu escrevo esse texto, o Claude Code tá me dando com frequência crescente o erro API Error: Request rejected (429) · Rate limited, o que também faz sentido: deve ser um combo de quota do meu plano e do Anthropic aplicando backpressure geral, porque eu não devo ser o único fazendo loucura esses dias. Ok, normal. É o preço de ter usado a ferramenta pesado quando fazia diferença.

Os outros dez por cento foram uma história separada.

Quando os LLMs comerciais dizem “não”

Meia dúzia de posts antigos se recusaram a ser traduzidos. Tanto Claude quanto GPT, pela API, caíam num erro 400 com mensagem de política de conteúdo. Tentei várias vezes, em sessões frescas, com contexto limpo. Nada.

A hipótese é simples: esses posts tocavam em tópicos sensíveis pra content moderation automatizado. Um post de 2009 sobre o discurso do Steve Jobs em Stanford de 2005 (que menciona câncer, já que o Jobs estava falando do diagnóstico terminal que ele tinha recebido). Dois capítulos antigos da Ayn Rand, traduzidos por mim anos atrás, sobre direitos do homem e argumentação. Um post anti-nazista que ironicamente foi bloqueado provavelmente só porque a palavra “nazi” aparecia lá, mesmo com o contexto sendo crítico. Um post sobre o discurso do dinheiro do Atlas Shrugged. E um ensaio sobre democracia e ética que travava sistematicamente todas as tentativas.

A ironia dessa parte é que o único jeito de conseguir traduzir esses posts foi usando um modelo open source. Carreguei o Qwen 3.5 35B no llama-swap, rodando localmente, sem filtros de política corporativa. O modelo leu, entendeu o contexto, e traduziu tudo sem drama. É o mesmo modelo que eu tinha testado extensivamente no meu último benchmark de LLMs, e que eu avalio como um dos melhores open source disponíveis hoje.

Ou seja: um modelo chinês conseguiu traduzir posts que modelos ocidentais recusaram. Eu não consigo deixar de achar isso levemente hilário. Ah, claro, e não posso falar mal da China (sarcasmo). LLMs comerciais vão sempre ter o problema de política corporativa e censura preventiva aplicada com régua meio grossa. É um trade-off real pra quem quer usar eles em produção: você ganha fluência e capacidade de raciocínio, perde controle quando o tópico resvala no que a empresa decidiu que é sensível.

O caso inverso: 2017-2018 traduzido pro português

Enquanto eu estava ajustando o Claude Code pra gerar o conteúdo em inglês, aproveitei pra resolver o problema simétrico. Os posts que eu tinha escrito originalmente em inglês durante 2017 e 2018, mais a série inteira de entrevistas “chatting-with” de 2008, estavam parados lá sem versão em português. Claude Code rodou o reverso: leu o inglês, gerou o português. Então se você não leu os originais em inglês (porque a maioria do meu público é brasileiro mesmo), agora você tem acesso também. Dá uma olhada na seção Off-Topic pra ver o que apareceu de novidade.

Junto disso, o Claude Code também atualizou o script generate_index.rb pra entender a estrutura bilíngue do blog e gerar dois índices separados, um em português e outro em inglês. O seletor PT/EN no rodapé de cada post aparece automaticamente quando existe o arquivo index.en.md irmão. Tudo bem integrado ao Hugo, seguindo o padrão nativo de multilíngue dele.

O ponto mais amplo

Aqui tá o recado que eu queria deixar nesse post de aniversário. Tradução em escala, centenas de artigos, conteúdo seu, na sua voz, respeitando o tom do original, era um problema caro e chato. Agora é um problema de fim de semana. Isso já tá no ar, você tá lendo o resultado. A barreira que existia pra alcançar audiência fora do Brasil virou algo barato o suficiente pra eu não ter mais desculpa.

Então, vamos lá, recapitulando o aniversário. 20 anos. 727 posts em português, construídos ao longo de cinco eras diferentes de tecnologia. 354 novos posts em inglês gerados num fim de semana. Metade do blog agora é bilíngue. E o resto vai indo. Os que faltam são principalmente posts antigos de ActiveAdmin, Rails 2 e dicas obsoletas que já faz sentido deletar ou não traduzir de propósito.

Se você tem amigo gringo que já cansou de ver você postando link em português e precisa de uma desculpa pra mandar alguma coisa minha, manda. Os posts principais sobre IA, os Chronicles, benchmarks, rants e boa parte do arquivo histórico já tão disponíveis em inglês no mesmo domínio, é só trocar o toggle no rodapé. Obrigado a todo mundo que acompanhou esse blog por esses vinte anos. Tem leitores aqui que me conhecem desde o Blogspot. Vocês sabem quem são.

Vamos pra mais um ano.

Mas o jogo que realmente me viciou no gênero simcade foi o Gran Turismo original, em 1997, no PlayStation 1. “The Real Driving Simulator” na capa. Eu joguei aquele jogo obsessivamente. Na mesma época eu assistia o anime Initial D, que estreou em 1998 no Japão. Comprei todos os mangás e li tudo do começo ao fim. A história do Takumi Fujiwara descendo o Monte Akina de madrugada entregando tofu no AE86 do pai dele é, pra mim, uma das melhores histórias de automobilismo já contadas em qualquer mídia.

Até hoje eu acompanho o trabalho do Shuichi Shigeno. Depois de Initial D veio MF Ghost (2017-2025), que se passa no mesmo universo mas num futuro próximo onde carros a combustão viraram peça de museu. E agora, desde julho de 2025, estou lendo Subaru and Subaru, a continuação direta que une os universos de Initial D e MF Ghost com duas protagonistas chamadas Subaru — uma de Gunma, outra de Kanagawa — competindo numa nova série de corridas. É o Shigeno no melhor dele.

Dois anos atrás eu viajei pro Japão com minha namorada e fiz questão de ir na Daikoku PA, o famoso parking area na Shuto Expressway em Yokohama onde a cultura JDM se concentra. Como fã antigo de Tokyo Xtreme Racer, da Genki, eu precisava ver Daikoku com meus próprios olhos pelo menos uma vez. E não decepcionou. Em vez de alugar carro, a gente fechou um tour com um guia local no Nissan GT-R preparado dele. Melhor assim. No caminho ele foi explicando a história da Wangan, como a cena funciona, o que é exagero de YouTube e o que é real. Quando chegamos numa sexta à noite e eu vi aquilo tudo ao vivo — Skyline R34, RX-7, Supra, GT-R, kei trucks tunados, bosozoku insanos — a sensação foi estranha no melhor sentido. Parecia Tokyo Xtreme Racer, só que com cheiro de combustível no ar e barulho de escapamento de verdade.

E tem outro detalhe: eu estou jogando o reboot novo de Tokyo Xtreme Racer no PC, e é exatamente o tipo de jogo que entende o próprio público. Campanha single-player forte, progressão viciante, clima certo, e sem aquelas palhaçadas de loot box. Recomendo fácil. Pelo mesmo motivo, eu também estou esperando muito o Forza Horizon 6, que dessa vez vai se passar no Japão. Eu já fiz a pré-compra e estou louco pra jogar isso no cockpit novo.

Dirigindo de verdade

Agora que estou semi-aposentado, tive a oportunidade de levar meu Mercedes em track days. Já andei no Autódromo de Interlagos (o Autódromo José Carlos Pace), circuito de 4.309 km em São Paulo que sedia o GP de F1 do Brasil desde 1973, famoso pelas curvas do S do Senna e pelo desnível maluco do circuito. Também andei no Autódromo Velocitta, um circuito moderno de 3.443 km inaugurado em 2014 em Mogi Guaçu, interior de São Paulo, que recebe a Stock Car Brasil e a Porsche Cup.

Em Las Vegas eu já dirigi super carros naquelas experiências de pista. E quando viajei com minha namorada pra Gramado, no RS, fomos na Super Carros, que fica na Av. das Hortênsias 4635. Eles têm um galpão de 2.400 m² com mais de 50 carros — Ferraris, Lamborghinis, Porsches, GT-Rs, Corvettes, muscle cars americanos. Você escolhe o carro, sai com um instrutor, e dirige um percurso de uns 17 km entre Gramado e Canela. Eu peguei um Nissan GT-R e uma Ferrari California.

Três anos atrás eu também fui pra Abu Dhabi com minha namorada e fomos no Ferrari World, que tem alguns dos melhores simuladores de corrida que eu já experimentei. Plataforma hidráulica com 6 graus de liberdade, cockpit de F1, a coisa toda. Eu sempre adorei testar simuladores onde quer que eu vá.

Mas dirigir carros de verdade em pistas de verdade é um hobby muito caro. Pneus, combustível, seguro, manutenção, inscrição. E o mais importante: eu sou introvertido. Prefiro estar sozinho. Meu cockpit de simulador é perfeito pra quando eu quero dirigir sem ter que lidar com ninguém. É por isso que eu gosto tanto de rally — sou eu, o co-driver virtual, e a estrada. Nada mais.

Os jogos que eu jogo

Sei que a maioria das pessoas que montam um cockpit como esse fazem pra jogar simuladores sérios — iRacing, Assetto Corsa Competizione, Automobilista 2. Eu respeito, mas não é minha praia. Não gosto de jogar online com outras pessoas. Não tenho nenhuma intenção de começar uma carreira de live streaming. Isso é puramente pro meu divertimento.

Atualmente eu jogo Gran Turismo 7 no PS5, Forza Motorsport (o 8, de 2023) no PC, mas onde eu me divirto mais é nos jogos de rally: EA SPORTS WRC, WRC 10 e DiRT Rally 2.0. Minha primeira experiência com Forza foi no Xbox One com o Forza Motorsport 5 e depois Forza Horizon 4, que me prendeu por centenas de horas.

E eu tenho um carinho enorme por jogos retro. O Colin McRae Rally original de 1998 no PS1 foi meu primeiro jogo de rally. Mas o meu favorito de todos os tempos é o Colin McRae Rally 2.0 (2000), também no PS1. Recentemente eu completei a campanha inteira de novo na versão de PC — dá pra achar repacks que rodam em alta resolução e widescreen, muito melhor que as versões originais de PlayStation. Recomendo pra qualquer um dos títulos da série.

Depois vieram Colin McRae 3 (2002), Colin McRae Rally 04 (2003) e Colin McRae 2005 (2004). Outros arcades que eu revisito com frequência: OutRun 2 SP (2004) e OutRun 2006: Coast 2 Coast (2006) — o melhor OutRun já feito, na minha opinião.

Mas meu jogo do ano, disparado, é o Super Woden: Rally Edge. Um indie feito por um desenvolvedor solo (ViJuDa, da Espanha) que lançou em janeiro de 2026 por menos de R$ 60. Oito países, mais de 80 carros, modo carreira, multiplayer local split-screen pra até 4 jogadores, leaderboards online. A câmera atrás do carro em vez do top-down dos Super Woden GP anteriores fez toda a diferença. 96% de reviews positivos no Steam com mais de 1.300 avaliações. É o tipo de jogo que mostra que você não precisa de orçamento milionário pra fazer algo incrível.

A evolução do meu setup de volante

Era Logitech G29 (~2015-2021)

Eu sempre quis um volante de corrida. Comecei há mais de 15 anos com algo equivalente ao volante de entrada da Logitech, um G29. O G29 é um bom volante pra começar — force feedback por engrenagens, pedais com embreagem, 900 graus de rotação. Mas o force feedback dele é barulhento e meio grosseiro. Você sente as engrenagens girando.

Era Thrustmaster T300RS + Suporte SXT V2 (~2021-2024)

Por volta de 2021 eu fiz o upgrade pro Thrustmaster T300RS, um volante por correia que é um salto enorme em relação ao Logitech. O force feedback é muito mais suave e preciso. E comprei o suporte Extreme Sim Racing SXT V2, que é bem mais robusto que aqueles suportes de mesa genéricos.

Primeiro eu montei o setup na frente do meu PC desktop, que na época tinha uma RTX 3090. Funcionava bem, mas era muito trabalhoso ficar montando e desmontando o suporte e os cabos toda vez que eu queria jogar.

Depois eu fiz um setup com cabo HDMI de fibra óptica longo pra conectar minha TV de 60" ao PC nos fundos da sala. Movi o suporte pra frente do sofá. Menos trabalhoso, mas eu ainda tinha que desmontar quando queria assistir filme com minha namorada.

Por volta de 2024 ou 2025 eu troquei meu sofá por um daqueles sofás VIP de cinema da Star Seat, que reclina e tudo. Problema: era muito mais alto que o sofá anterior. Tive que fazer todo tipo de gambiarra pra fazer o suporte funcionar naquela altura. Cheguei a imprimir suportes em 3D e mandar pra PCBWay usinar placas de aço pra prender rodas grandes embaixo do suporte e ganhar uns centímetros de altura. Mas isso deixou o setup muito instável pra dirigir confortavelmente.

Era Fanatec CSL DD + Direct Drive (~2024-2025)

Nesse meio tempo eu dei o T300 pro meu irmão e fiz o upgrade pra um Fanatec CSL DD Gran Turismo Edition. O motor direct drive do CSL DD entrega 5 Nm de torque na base, mas o kit Gran Turismo DD Pro já vem com o Boost Kit 180 que sobe pra 8 Nm sustentados sem cooling ativo. Direct drive significa que não tem engrenagem nem correia entre o motor e o volante — o eixo do motor É o eixo do volante. A diferença é absurda. O T300 já era ótimo, muito superior ao Logitech. Mas o Fanatec está em outro patamar. Você sente cada textura do asfalto, cada lombada, cada derrapagem incipiente. Não tem como voltar atrás depois que experimenta.

Comprei junto o kit de pedais CSL com Load Cell, que mede pressão no freio em vez de deslocamento. Faz toda a diferença na frenagem — você aprende a dosar pela força do pé, não pela distância que o pedal percorre. Muito mais natural.

Eu também quis experimentar o câmbio manual H-pattern com o ClubSport Shifter SQ V1.5 da Fanatec e o freio de mão separado. É legal pra experimentar carros antigos com embreagem e câmbio H, mas na prática eu não me adaptei. O suporte SXT V2 já balançava bastante com o direct drive, e usar o shifter naquele setup instável era frustrante. E eu sei que tem gente que quer fazer “ponta e calcanhar” (heel-toe), mas no simulador eu prefiro ter o pé esquerdo no freio e o direito no acelerador e dosar os dois ao mesmo tempo. Funciona melhor pra mim. Agora que eu tenho o volante McLaren com os paddles analógicos de freio de mão e embreagem direto no volante, o câmbio H e o handbrake externo ficaram aposentados. Pra rally, o handbrake analógico no volante é muito mais natural.

Também comprei o PS5 com Gran Turismo 7 nessa época. Coloquei as dbrand Darkplates matte black pra trocar as placas brancas originais — fica muito mais bonito e discreto.

Mas o setup ainda era o suporte SXT V2 na frente do sofá VIP. A mesma gambiarra. O mesmo balanço. Eu não ia desistir do sofá de cinema, claro. A situação ficou insustentável.

O computador e o setup de hardware

Uma nota sobre meu hardware de gaming. Eu comprei um Minisforum UX790 Pro pra ser minha máquina dedicada de Steam. É um mini-PC com processador Intel Core Ultra 9 285H, que cabe na palma da mão. Junto comprei o Minisforum DEG1, um dock de GPU externo que conecta via OCuLink (PCIe 4.0 x4, 64 GT/s). É um design aberto — basicamente uma placa com slot PCIe x16 e espaço pra fonte ATX ou SFX. Não tem limitação de tamanho de placa, então cabe uma RTX 4090 tranquilamente. A perda de performance comparado a um slot PCIe nativo é mínima. Coloquei a RTX 4090 nele. A 4090 veio do meu desktop — no começo de 2025 eu viajei pra Miami e aproveitei pra comprar uma RTX 5090 porque estava usando cada vez mais IA e LLMs locais. Dei a 3090 antiga pra minha namorada usar na edição de vídeo. A 4090 foi pro mini-PC.

Então meu setup de gaming hoje é: Minisforum UX790 Pro + eGPU com RTX 4090 pra Steam e jogos de PC, e PlayStation 5 com Darkplates matte black pra Gran Turismo 7 e exclusivos.

O cockpit: Formula FX1

Pra completar o setup eu também precisava de um monitor decente. Eu já estava acostumado com minha TV OLED Samsung de 80" na sala e não queria dar um downgrade na qualidade de imagem. Então investi no Samsung Odyssey OLED G8 de 32". É um monitor 4K (3840x2160) OLED com 240 Hz de refresh rate, 0.03 ms de tempo de resposta (GTG), HDR True Black 400, HDR10+, 99% de cobertura DCI-P3, contraste de 1.000.000:1, e FreeSync Premium Pro. Tem 2 entradas HDMI 2.1 e 1 DisplayPort 1.4.

Na prática: as cores explodem, preto é preto de verdade (é OLED, não tem backlight), e com a RTX 4090 eu rodo a maioria dos jogos em 4K a 120 fps tranquilo. Em títulos mais leves como o Super Woden: Rally Edge, chega fácil nos 240 Hz. A fluidez é absurda. Pra um cockpit onde você está a uns 60-70 cm da tela, 32" OLED em 4K é o sweet spot. Maior que isso e você começaria a enxergar pixels. Menor e perde a imersão.

Em janeiro de 2026, depois de anos de gambiarra, eu finalmente encomendei um cockpit dedicado. Pesquisei bastante. Considerei o Cockpit AX160, que é de perfil de alumínio e muito modular, e o Cockpit 4.0, que é de aço tubular mais tradicional. Mas nenhum dos dois estava disponível no momento da compra. E aí eu encontrei o Formula FX1 preto e verde da Extreme Racing — cores Petronas, estilo F1.

O FX1 é muito diferente dos cockpits tradicionais. A estrutura inteira é de tubos de aço grossos, soldados. Quando eu digo que a coisa não balança, eu quero dizer que não balança nada. Zero wobble. É uma diferença brutal em relação ao suporte na frente do sofá. A posição de pilotagem é reclinada, tipo F1 — seus pés ficam na mesma altura ou mais altos que seu quadril. Parece que vai ser desconfortável, mas não é. Dá pra ficar horas ali sem reclamar. Vem com banco acolchoado e ajustável, suporte pra monitor com articulação, suporte pra pedais com inclinação ajustável, e suporte pra volante com altura regulável.

Tive que esperar cerca de 1 mês pela entrega. No meio tempo, como quem acompanha meu blog sabe, eu mergulhei numa maratona de 16 horas por dia testando os novos agentes de IA da Anthropic e OpenAI — veja as tags #vibecoding e #agents pra ver tudo que eu fiz. Depois de uns 30 dias nessa maratona insana, minha lombar cedeu e eu comecei a desenvolver o que parece ser hérnia de disco. Tive que ir ao médico e tomar anti-inflamatórios pesados.

E exatamente nessa semana, o cockpit decidiu chegar.

A montagem

Eu estava com dor absurda, mas montei o cockpit assim mesmo. Levou o dia inteiro pra desembalar e montar as peças de aço pesadas com a lombar gritando, mas eu fiz.

O vídeo de montagem oficial que eu segui:

O volante McLaren GT3 V2

Depois de montar o cockpit, eu decidi que o volante padrão que vem com o kit CSL GT não era suficiente. Fiz o upgrade pro Fanatec CSL Elite McLaren GT3 V2 (~R$ 4.990). É uma réplica em escala real do volante do McLaren GT3, com fibra de carbono, display OLED, e compatível com PC, Xbox, PS4 e PS5.

O que eu mais gosto nele: tem as borboletas de câmbio normais atrás (shift up/down), mas também tem dois paddles analógicos adicionais que podem ser configurados em quatro modos diferentes. No modo B, que é o que eu uso, o paddle esquerdo funciona como handbrake analógico e o direito como embreagem analógica. Isso é perfeito pra rally — eu consigo puxar o freio de mão no meio da curva sem tirar a mão do volante. Tem também dois toggles de 2 posições, dois rotary de 12 posições, 7 botões padrão com caps intercambiáveis, e o FunkySwitch de 7 direções da Fanatec. É um controle completo de corrida.

O setup final

O cockpit ficou num cantinho do meu quarto, entre as estantes de mangá (dá pra ver Akira, Initial D, e uns 500 outros volumes atrás). Montei o mini-PC e o PS5 na estrutura lateral do cockpit, junto com a eGPU e a RTX 4090. Tudo fica permanentemente conectado. É isso que faz a diferença: eu não preciso mais montar nem desmontar nada. Sento, ligo, e estou dirigindo em 30 segundos.

O sistema de áudio

Pra completar o setup eu precisava de áudio dedicado. Eu não queria usar o áudio do monitor (péssimo) nem ficar sempre de headset. A solução foi montar um sistema de áudio separado com extração de áudio do HDMI.

A peça central é um switcher HDMI 2.1 da OREI com extração de áudio. Ele tem 2 entradas e 1 saída HDMI, suporta 4K a 120Hz (48 Gbps de bandwidth), e extrai o áudio via saída óptica TOSLINK e P2 3.5mm. Eu conecto a saída HDMI da RTX 4090 numa entrada e o PS5 na outra. O vídeo vai pro monitor. O áudio sai pela óptica.

O áudio óptico vai pra um amplificador Aiyima D03, um amp compacto 2.1 canais com 150W por canal, DAC integrado (chip PCM1808), e Bluetooth 5.0 com aptX HD. Ele tem entrada óptica, coaxial, USB, RCA e Bluetooth. Tem até saída dedicada pra subwoofer quando eu resolver adicionar um. Usa chip amplificador TAS5624 da Texas Instruments e tem controle de graves e agudos pelo controle remoto. Pra um setup de cockpit onde você está a 1 metro das caixas, 150W é mais que suficiente.

Na prática, eu deixo o amplificador em 50% e o volume do Windows em 50%, e isso já fica alto pra caramba. Ou seja: não é um sisteminha “quebra-galho”. Está equipado pra tocar realmente alto se eu quiser.

As caixas são Edifier P12, passivas, com woofer de 4 polegadas e tweeter de 19mm. Resposta de frequência de 55Hz a 20kHz, impedância de 6 ohms, potência de 20W RMS cada. O gabinete de MDF com acabamento em madeira tem um porte-reflex traseiro que ajuda nos graves. Pra caixas passivas desse tamanho, elas entregam bem. O mid-range sai limpo e os agudos não distorcem mesmo no volume alto.

A lógica do setup é: HDMI switcher faz o chaveamento entre PS5 e PC, extrai o áudio pra óptica, o amp converte e amplifica, e as caixas passivas entregam o som. Tudo sem precisar tocar no monitor ou trocar cabos. Aperto um botão no switcher e troco de console.

Quando eu quero jogar sem incomodar ninguém, conecto meu Meze 109 Pro direto na saída P2 do switcher HDMI. O Meze 109 Pro é um headphone aberto com drivers dinâmicos de 50mm, impedância de 40 ohms, sensibilidade de 112 dB SPL/1mW, e resposta de 5Hz a 30kHz. Os ear cups são de madeira de nogueira com acabamento artesanal. É um headphone audiófilo que funciona perfeitamente sem amplificador dedicado graças à impedância baixa. O som é quente, com graves cheios e mids ricos. Dá pra ouvir cada detalhe do ronco dos motores.

Ainda não decidi sobre subwoofer, mas vai ser meu próximo upgrade. Um sub dedicado vai adicionar aquele peso nos graves que faz você sentir o motor no peito.

O veredito

O sofa com suporte funciona. A mesa do PC com suporte funciona. Mas nenhum dos dois chega perto de um cockpit dedicado. A estrutura de aço do FX1 não mexe nem um milímetro, mesmo com o direct drive do Fanatec dando torque máximo. A posição F1 reclinada é confortável pra sessões de horas. Os pedais com load cell ficam firmes na base. O monitor fica exatamente na altura e distância certas. E o melhor de tudo: está sempre pronto. Eu não preciso montar, desmontar, passar cabo, nada. Sento e dirijo.

Pra quem está na dúvida se vale a pena investir num cockpit dedicado vs. ficar com suporte na mesa ou no sofá: vale. Se você já tem um volante direct drive, o cockpit é a peça que falta. Eu passei anos achando que “tá bom assim” com o suporte no sofá. Não tava. A diferença na dirigibilidade é outra coisa. E pro meu caso — introvertido, single-player only, simcade — não podia ter montado antes. Pra falar a verdade, eu acho que finalmente cheguei no meu setup de simulador perfeito pro meu gosto.

Lista de compras: quanto custou tudo

Aqui está a lista consolidada de tudo que compõe meu setup atual, com preços aproximados (alguns comprei em dólar, converti pra real na cotação da época):

Sim, quase R$ 57 mil é bastante dinheiro. Eu trabalhei feito um condenado por décadas. Agora que consegui me aposentar honestamente, minha família está bem amparada, não tenho dívidas, e eu posso finalmente me dar algo que eu sempre quis quando era moleque mas não tinha como bancar. Quando eu sentava naqueles cabinets de OutRun e Daytona USA no fliperama, eu sonhava em ter algo assim em casa. Levou 30 e poucos anos, mas cheguei lá.

E se você somar os anos de gambiarras, suportes que não funcionavam, cabos HDMI de 15 metros, impressões 3D, placas de aço usinadas, e a frustração de montar e desmontar tudo — o cockpit dedicado economiza sanidade. Diferente de um PC que deprecia rápido, um cockpit de aço dura décadas.

O resultado foram 653 commits, ~144K linhas de código em 8 projetos publicados no GitHub, e uma série de artigos documentando cada um deles. Se você acompanhou, já leu os post-mortems. Se não acompanhou, aqui vai o índice:

Os artigos

• Vibe Code: Eu fiz um appzinho 100% com GLM 4.7 (TV Clipboard)
• Vibe Code: Qual LLM é a MELHOR?? Vamos falar a REAL
• Vibe Code: Fiz um Editor de Markdown do zero com Claude Code (FrankMD) PARTE 1
• Vibe Code: Fiz um Editor de Markdown do zero com Claude Code (FrankMD) PARTE 2
• RANT: IA acabou com os programadores?
• Vibe Code: Do Zero à Produção em 6 DIAS - The M.Akita Chronicles
• Do Zero à Pós-Produção em 1 Semana - Como usar IA em Projetos de Verdade
• Vibe Code: Fiz um clone do Mega em Rails em 1 dia pro meu Home Server
• Vibe Code: Fiz um Indexador Inteligente de Imagens com IA em 2 dias - Frank Sherlock
• RANT: o Akita abriu as pernas pra IA??
• ai-jail: Sandbox para Agentes de IA
• Software Nunca Está ‘Pronto’ - 4 Projetos, a Vida Pós-Deploy
• Eu Fiz um Sistema de Data Mining pra Minha Namorada Influencer
• Meu primeiro fracasso com Vibe Code e como Consertei - Frank Yomik

Os projetos

Isso tudo aconteceu entre 27 de janeiro e 5 de março de 2026.

Não vou repetir os detalhes técnicos de cada projeto. Cada post-mortem acima já cobriu isso. O que eu quero discutir aqui é a consequência.

O que esses 37 dias me mostraram

Projetos que antes levariam semanas ou meses pra um desenvolvedor experiente agora levam dias. Um editor de Markdown completo em 5 dias. Um clone do Mega em 1 dia. Um sistema de data mining com 40+ ferramentas de bot em 3 dias. Um indexador de imagens com vision AI em 2 dias.

E não estou falando de protótipos jogados fora. Esses projetos estão em produção. Têm testes. Têm deploy automatizado. São software de verdade construído com práticas de engenharia de verdade, só que com velocidade que antes era impensável.

Essa velocidade não é exclusiva minha. A Cloudflare acabou de demonstrar algo parecido. Num post recente, eles descrevem como um engenheiro reimplementou o surface de API do Next.js sobre Vite em uma semana, usando Claude como ferramenta principal. US$ 1.100 em tokens de API, mais de 800 sessões, 1.700 testes unitários, 380 testes E2E, builds 4.4x mais rápidos que o Next.js original. Controvérsias à parte sobre se é uma reimplementação “completa” ou não, o ponto central é real: software que antes exigia equipes e meses agora pode ser construído por uma pessoa em dias.

E isso muda tudo pra quem quer empreender.

A morte da startup fácil

Durante anos, o modelo clássico de startup funcionava assim: alguém tem uma ideia, monta uma equipe pequena, desenvolve um MVP em 3-6 meses, levanta seed money, e tenta escalar. A barreira de entrada era o custo de desenvolvimento. Programadores são caros, desenvolvimento é lento, e o primeiro a chegar no mercado tem vantagem.

Esse modelo está quebrando.

Se eu consigo fazer um clone funcional do Mega em 1 dia, quanto vale a startup de “cloud storage”? Se a Cloudflare reimplementa o core do Next.js em 1 semana com um engenheiro e US$ 1.100 em tokens, qual é o moat real de uma plataforma como Vercel? O SaaS de “social listening” que cobra R$ 500/mês compete com algo que eu fiz em 3 dias como side project.

Todo aquele empreendedor que chegava descrevendo sua ideia como “é tipo um Uber, mas pra…” ou “é como Airbnb, só que…” ou “mais uma rede social, mas com…” – essas pessoas precisam parar e repensar. Quando qualquer desenvolvedor competente com acesso a Claude Code ou GPT Codex consegue replicar seu MVP numa semana, sua ideia não vale mais nada. A execução ficou barata demais.

Não estou exagerando. Nos meus 37 dias, eu fiz coisas que antigamente eu não faria nem em 6 meses. Pequenos CRMs, ecommerces, gerenciadores de conteúdo, ferramentas de produtividade, apps de data mining, pipelines de processamento – tudo isso virou commodity. O código em si não é mais diferencial.

O que é diferencial, então?

Aqui entra a parte que a maioria dos entusiastas de vibe coding ignora. Pra ilustrar, vou usar meu próprio projeto como exemplo.

O Frank Yomik traduz páginas de mangá de japonês pra inglês em tempo quase real. O pipeline inteiro (detecção de balões, OCR, tradução, renderização) funciona. Mas o componente mais importante do sistema não é nenhum código que eu escrevi. É o modelo ogkalu/comic-text-and-bubble-detector, um RT-DETR-v2 treinado em ~11.000 imagens rotuladas de quadrinhos.

Eu não treinei esse modelo. Eu não poderia treinar esse modelo facilmente. Coletar 11.000 imagens de quadrinhos diversas, rotular manualmente os balões de fala em cada uma (ou gerar labels com alguma pipeline semi-automatizada, o que também não é trivial), configurar o treinamento, e rodar no hardware necessário – isso é trabalho de natureza diferente. É trabalho que vibe coding não resolve.

E esse é o caso de um modelo relativamente pequeno. Um detector de objetos pode ser treinado com algumas centenas a milhares de imagens rotuladas numa única GPU em horas. Estudos mostram que resultados úteis são possíveis com 100-350 imagens pra domínios específicos, mas detectores robustos pro mundo real geralmente precisam de milhares. O custo é baixo, na casa de centenas de dólares.

Agora olha o que acontece quando subimos pra modelos maiores.

Os números que importam

O GPT-4 custou mais de US$ 100 milhões pra treinar, segundo o próprio Sam Altman. A Stanford estimou o custo de compute do Gemini Ultra do Google em US$ 191 milhões. O Llama 3 da Meta consumiu 39,3 milhões de GPU-horas em H100s, e a Meta montou dois clusters de 24.576 GPUs cada pra viabilizar isso – e até o final de 2024, planejava ter 350.000 H100s na sua infraestrutura.

Esses custos estão acelerando. Segundo a Epoch AI, o custo de hardware e energia pra treinar modelos de fronteira cresce a 2,4x por ano desde 2016. Se essa tendência continuar, os maiores treinamentos vão custar mais de US$ 1 bilhão antes do fim de 2027. O Dario Amodei, CEO da Anthropic, já disse que desenvolvedores de fronteira provavelmente estão gastando perto de um bilhão por treinamento agora, com treinamentos de US$ 10 bilhões esperados em dois anos.

E o hardware? Uma GPU H100 custa US$ 25.000-40.000 por unidade. Um servidor com 8 GPUs sai entre US$ 200.000 e US$ 400.000. A memória HBM que essas GPUs usam está com capacidade esgotada – SK Hynix, Samsung e Micron já anunciaram aumentos de ~20% nos preços pra 2026. A NVIDIA consome mais de 60% da produção global de HBM. É um gargalo estrutural, não temporário.

Em termos de energia: data centers globais consumiram ~415 TWh de eletricidade em 2024, segundo o IEA, cerca de 1,5% da eletricidade mundial. A projeção é ~945 TWh até 2030. Novos data centers estão sendo construídos com capacidades de 100 MW a 1 GW cada.

E os investimentos das big techs refletem isso. Em 2025, os gastos de capital agregados de Amazon ($125B), Google ($91B), Microsoft ($80B) e Meta ($71B) passaram de US$ 400 bilhões, crescimento de 62% sobre 2024. Goldman Sachs projeta mais de US$ 500 bilhões em 2026.

Esses números não são pra assustar. São pra contextualizar de onde vem a barreira de entrada real.

A nova barreira: dados exclusivos e capacidade de treinamento

Se software ficou barato de produzir, o diferencial competitivo migrou. A pergunta deixou de ser “quem escreve o código mais rápido?” e virou “quem tem acesso a dados que ninguém mais tem, e sabe transformar esses dados em modelos úteis?”

O DeepSeek-V3 anunciou que seu treinamento custou US$ 5,5 milhões em compute. A imprensa celebrou o “modelo barato chinês”. Mas o The Register reportou que o custo de aquisição dos 256 servidores GPU usados foi de mais de US$ 51 milhões – e isso exclui R&D, aquisição de dados, limpeza de dados, e todos os treinamentos fracassados antes do run final que deu certo. O custo real de desenvolver a capacidade é uma ou duas ordens de grandeza acima do custo marginal do treinamento final bem-sucedido.

É por isso que só vemos grandes empresas produzindo modelos de fronteira. Meta, Alibaba, Google, Amazon, Microsoft, Anthropic – empresas que investem dezenas de bilhões em hardware e energia. Uma startup em garagem não consegue competir nessa dimensão.

Mas a questão vai além de modelos de fronteira. Mesmo modelos especializados menores exigem algo que não se compra: dados proprietários de qualidade.

O Llama 3 foi treinado em 15 trilhões de tokens. A Epoch AI já documentou que estamos nos aproximando dos limites de dados textuais gerados por humanos na internet. Dados públicos estão sendo exauridos. Quem tem dados exclusivos – dados médicos, financeiros, industriais, logísticos, de sensores, de comportamento de usuário – tem algo que não pode ser replicado por vibe coding.

E mesmo quem treina modelos especializados com dados proprietários enfrenta um problema: a vantagem é temporária. Outro competidor pode coletar dados similares e treinar um modelo concorrente em meses. O diferencial precisa ser continuamente alimentado: mais dados, melhor curadoria, pipelines de treinamento mais eficientes, acesso a hardware que está cada vez mais escasso e caro.

O cenário

Se você está pensando em montar uma startup, a pergunta que importa mudou.

Antes era: “consigo construir esse software?” Agora a resposta é quase sempre sim, rápido e barato.

A pergunta agora é: “tenho dados exclusivos que ninguém mais tem, e sei como transformar esses dados em algo útil que seja difícil de replicar?”

Se a resposta for não, qualquer concorrente com Claude Code replica seu produto em dias. E depois aparece outro. E outro. A corrida pro fundo em preço é imediata quando o custo de construir é próximo de zero.

Se a resposta for sim, você tem um moat real – mas temporário. Modelos concorrentes treinados em dados similares podem aparecer em meses. Seu diferencial precisa ser continuamente alimentado.

A era das startups fáceis acabou. Não porque ficou mais difícil construir software – ficou muito mais fácil. Mas justamente por isso: quando todo mundo consegue construir a mesma coisa em uma semana, a vantagem competitiva precisa vir de outro lugar. E esse “outro lugar” requer capital e infraestrutura que são ordens de grandeza mais caros do que escrever código.

A garagem ainda funciona. Mas o que sai dela não pode mais ser “um app”.

–

Publiquei o “post final” da série Bastidores do The M.Akita Chronicles há 10 dias. 274 commits, 1.323 testes, deploy em produção. Escrevi as lições, fiz a conclusão, coloquei a citação no final. Done.

125 commits de pós-produção depois, posso confirmar: software “done” não existe.

Hoje o repositório do M.Akita Chronicles tem 335 commits e 1.422 testes. Amanhã, segunda-feira, os assinantes recebem a 3ª newsletter consecutiva — gerada, revisada, e enviada por um sistema que não para de evoluir. Enquanto isso, o Frank Sherlock saiu de 50 commits e v0.1 pra 103 commits e v0.7 com face detection. O FrankMD recebeu 3 contribuidores externos e lançou a v0.2.0. E até o FrankMega — um projeto construído em 1 dia — precisou de correções quando usuários reais apareceram.

Ao longo de fevereiro, publiquei mais de uma dezena de posts detalhando a construção de cada projeto. Este post é diferente. Não é sobre construir do zero, já cobri isso. É sobre o que acontece depois. E o que acontece depois destrói a narrativa do one-shot prompt. Software precisa de um humano experiente no volante. Desenvolvimento iterativo é a única forma que funciona. Quem discorda não botou sistema em produção ainda.

Vou provar com git log.

A Vida Depois do Deploy

Vamos aos detalhes.

The M.Akita Chronicles: 3 Semanas em Produção

O sistema de newsletter está no ar desde 16 de fevereiro. Já enviou 2 newsletters e amanhã envia a terceira. 56 commits aconteceram desde o “post final”:

Features que Ninguém Previu

Steam Gaming. Não existia no plano original. Nasceu porque a seção de entretenimento só tinha anime — e leitores gamers ficaram de fora. Resultado: 6 commits só no dia de lançamento. O primeiro commit (bf41e25) adicionou a seção completa — serviço de API Steam, job de geração, testes, shortcode Hugo. Os 5 seguintes corrigiram: parsing de datas em português, offset pro ranking não repetir o top 10, filtro de wishlist pra releases, dark theme. Nenhum spec do mundo prevê que a API do Steam retorna datas com abreviações em português ("fev", "mar", "abr") quando você pede l=brazilian. Isso você descobre quando o parser quebra em produção.

Sistema de preview. O /preview nasceu porque eu precisava ver como o conteúdo auto-gerado ficava antes de publicar a newsletter inteira. Parece óbvio em retrospecto, mas na v1 a única forma de validar era gerar tudo e olhar o resultado final. 5 commits pra construir um sistema de preview com 9 seções, aliases (hn pra hacker_news, steam pra steam_gaming), modo de preview de comentários separado, e rescue quando uma seção falha sem derrubar as outras (d23c725 — porque uma seção com erro estava matando o preview inteiro).

Moods do Marvin. O Marvin (a persona sarcástica do bot) sofre de um problema crônico de LLMs: suavização. Sem intervenção, todo comentário vira o mesmo tom morno. A solução iterativa foi um sistema de moods — 9 modos que o operador escolhe por story:

MARVIN_MOODS = {
  "sarcastic"   => "Be extra sarcastic and biting in your commentary.",
  "ironic"      => "Use irony and dark humor to make your point.",
  "grounded"    => "Be more neutral and journalist-like, factual and measured.",
  "provocative" => "Be provocative and controversial, challenge assumptions.",
  "counter"     => "Take the opposite position from Akita's comment.",
  "insightful"  => "Find a non-obvious angle -- a historical parallel, a second-order consequence.",
  "positive"    => "Find the genuinely positive angle.",
  "hopeful"     => "Be cautiously optimistic. Acknowledge the good potential.",
  "negative"    => "Be extra pessimistic and bleak."
}.freeze

Nada disso surgiu de uma spec. Surgiu de 3 semanas lendo comentários genéricos e pensando “isso não tá bom”. São 7 commits só de prompt tuning ao longo de 10 dias. Bani padrões formulaicos (d4bd3a6). Eliminei o “Ah,” como abertura (4171628). Removi o Marvin de seções inteiras do podcast porque ele tava contaminando o tom (246cc60). Forcei substância ao invés de trocadilhos (8bc47c4). Cada commit de prompt é uma micro-correção que só faz sentido depois de ler o output anterior.

Bugs que Só Existem em Produção

Dos 56 commits, 13 são bug fixes. Alguns favoritos:

• Gmail clipping (3258f5b): Gmail silenciosamente corta emails maiores que 102KB. Descobri quando a 2ª newsletter saiu mais longa e leitores no Gmail não viram o final. Resultado: um check de tamanho no content preflight que avisa antes de publicar. Reduzi as seções de história de 10 pra 5 itens (51ce528) pra caber no limite.

• False paywall detection (1fd8739): o scraper marcava sites como paywall quando encontrava texto de bloqueio acidental num rodapé genérico. Só apareceu quando a lista de stories cresceu pra dezenas de fontes reais.

• t.co link mangling (6bd056f): o Twitter encurta URLs com t.co, mas também auto-linka nomes de arquivo que parecem domínios. config.yml vira um link pro domínio config.yml. 158 linhas de fix pra tratar corretamente textos de tweet.

• TTS language revert (7803ad9 -> c1dd668): tentei trocar o idioma do TTS de “Portuguese” pra “Auto”. O modelo gerou sotaque misturado. Revertido no mesmo dia.

• Podcast section ordering (5bef18c): seções do podcast saíram fora de ordem. Fix de 3 linhas + untrack de 1.504 linhas de conteúdo gerado que foi commitado por acidente.

• Elementor sites com múltiplos <article> (e70b756): sites construídos com Elementor usam a tag <article> de forma não-semântica. O extrator de conteúdo pegava o bloco errado. 171 linhas de fix + testes.

Nenhum desses bugs poderia ter sido previsto numa spec. Eles só existem porque o sistema tá no ar, processando dados reais, batendo em APIs reais, sendo lido por gente real.

De 1.323 pra 1.422 Testes

A suíte de testes continuou crescendo junto:

Feature nova? Vem com teste. Bug fix? Vem com teste de regressão. Sem isso, os 56 commits de pós-produção seriam 56 oportunidades de quebrar algo que funcionava ontem. TDD não é fase, é hábito.

O Modelo Mudou: De Claude pra Grok-4

Commit 8f9d11c: Switch default model to x-ai/grok-4. A arquitetura isolou o modelo LLM numa variável de ambiente desde o início. Mas o nome do modelo ainda estava referenciado em código por 24 arquivos. Resultado: commit c8c688e — Centralize LLM model config — 24 arquivos tocados pra garantir que trocar de modelo seja uma mudança de 1 linha de config.

Esse tipo de refactoring só surge na operação. Quando você começa o projeto, não sabe que vai trocar de modelo. Quando troca, quer que seja trivial. E a limpeza pra tornar trivial? Só acontece quando a dor aparece.

Frank Sherlock: De v0.1 a v0.7 em 4 Dias

O post sobre o Frank Sherlock cobriu os primeiros 2 dias e ~50 commits: a pesquisa de benchmarks, o scaffold do app Tauri (Rust + React), a pipeline de classificação com Ollama, e o lançamento da v0.1.0 com binários pra Linux, macOS e Windows.

O que o post não cobriu: os 53 commits seguintes, em 4 dias, que levaram o projeto da v0.3 pra v0.7:

Face Detection: A Feature que Nasceu da Iteração

A v0.1 era um indexador de imagens com classificação por LLM. A v0.7 tem detecção de rostos com embeddings de 512 dimensões, clustering por similaridade de cosseno, e busca por pessoa (face:alice). Nada disso tava no plano original. Surgiu porque comecei a usar o app com fotos de verdade e pensei “quero encontrar todas as fotos de fulano” A feature nasceu do uso, não da spec.

O caminho até lá foi metódico:

1. f34132f: A/B testing framework pra face detection — benchmarkear antes de implementar, não depois
2. ef3be82: Resultados do A/B (SCRFD + ArcFace venceu)
3. 6d9174a: Implementação nativa com ONNX Runtime — sem Python, sem dependência externa
4. 3b25eaf: Clustering, person management, FacesView completa
5. a02d67f: Refactoring — extrair helpers, deletar código morto, compartilhar CSS

Benchmark -> implementar -> refatorar. O mesmo ciclo de sempre. E algo que nenhum one-shot prompt produz.

Video Support: Outro Emergente

O app foi pensado pra imagens. Mas pastas reais de mídia têm vídeos. Commit a67a2f9 adicionou suporte completo: scanning de 11 formatos (MP4, MKV, AVI, MOV, WebM…), extração de keyframe pra classificação pelo LLM, skip de frames pretos, parsing de legendas .srt pro índice full-text, e preview inline com streaming HTTP Range.

1.626 linhas adicionadas num commit. Uma feature inteira que nasceu do uso real, não de uma especificação.

7 Releases, 3 Plataformas, AUR Automático

Em 7 dias, o Frank Sherlock teve 7 releases. Cada um com binários compilados pra Linux (AppImage), macOS (DMG com notarização e code signing), e Windows (MSI). A pipeline de CI/CD (release.yml) faz tudo automaticamente. A partir da v0.5.0, um workflow adicional (aur-publish.yml) publica automaticamente no AUR — o repositório de pacotes do Arch Linux.

No final: 17.210 linhas de Rust, 10.863 linhas de TypeScript, 621 testes (322 Rust + 299 frontend). Cross-platform. Releases publicados e instaláveis por qualquer usuário. Uma semana, um dev, um agente de IA.

A parte de CI/CD pra cross-platform é onde a fantasia do “funciona na minha máquina” morre. Foram 17 commits só de build: Windows UNC paths, macOS signing com notarização, Linux AppImage, permissões de release workflow, macOS Intel target removido. Nenhum LLM do mundo sabe que o macOS exige entitlements específicos pra hardened runtime ou que paths no Windows começam com \\?\. Esse tipo de trabalho de deploy exige alguém que já passou por essa dor antes.

FrankMD: Open Source de Verdade

O FrankMD foi o primeiro projeto desta saga, um editor Markdown self-hosted com Rails 8. Os posts de fevereiro cobriram a construção. O que aconteceu depois é mais interessante: outras pessoas começaram a contribuir.

14 commits desde 20 de fevereiro. 3 contribuidores externos. 4 PRs merged. Release v0.2.0 no dia 28:

O Padrão do Maintainer

O mais revelador não são as contribuições em si, mas o que eu fiz depois de cada merge.

Quando o @LuccaRomanelli submeteu o PR do Omarchy theme sync (+308 linhas), eu mergeei e imediatamente commitei fix: harden Omarchy theme integration and fix broken tests — +163 linhas de fixes e testes no commit seguinte. O contribuidor implementou a feature. O maintainer endureceu.

Quando o @rafaself submeteu o fix de table hints, foram 3 commits iterativos no mesmo dia — enhance, improve, streamline — mostrando o mesmo padrão de refinamento progressivo que eu faço com o agente de IA. No dia seguinte, ele mandou um commit separado atualizando faraday, nokogiri e rack por security advisories.

No dia 28, sentei e fiz tudo de uma vez: mergeei as 4 PRs, commitei o hardening, atualizei 5 gems (brakeman, bootsnap, selenium-webdriver, web-console, mocha), e publiquei as release notes da v0.2.0. Um “release day” clássico.

O FrankMD hoje tem 226 commits, 1.804 testes (425 Ruby + 1.379 JavaScript), e contribuidores ativos. Não é mais “meu projetinho pessoal”. Virou software com comunidade. E comunidade não aparece pra protótipo sem testes que “funciona na minha máquina”. Aparece pra projeto com CI verde, documentação, releases versionados, e código que dá pra ler.

FrankMega: Até o Menor Projeto Precisa de Pós-Produção

O FrankMega foi construído em 1 dia. 26 commits, file sharing seguro com Rails 8, 210 testes, deploy via Docker + Cloudflare Tunnel. Post publicado no mesmo dia. Pronto, certo?

Três dias depois, 2 commits:

• db4bb705 — Add macOS, Linux, and Windows package MIME types to seed defaults
• b0c4829a — Fix MIME types to match Marcel detection, add normalizes strip

Usuários tentaram compartilhar arquivos .dmg, .deb, e .msi. O MIME type detection (via gem Marcel) não reconhecia esses formatos porque não estavam nos defaults do seed. Dois commits. 22 linhas. 15 minutos.

Mas sem eles, o FrankMega não servia pra compartilhar pacotes de instalação — que é exatamente o caso de uso mais comum num home server de devs.

Nenhum prompt no mundo prevê que seus usuários vão querer compartilhar .deb no primeiro dia.

O projeto mais simples de todos, com a pós-produção mais curta. E mesmo assim, precisou de iteração.

Os Números Consolidados

692 commits. 4.057 testes. 4 projetos em produção. Fevereiro de 2026. Eu e um agente de IA.

Por Que One-Shot Prompt É Mito

Olha os 125 commits de pós-produção e me diz qual deles poderia ter sido previsto por uma especificação.

Gmail corta emails maiores que 102KB, e você só descobre quando manda o primeiro email longo. A Steam API retorna datas com abreviações em português ("fev", "abr"), e você só descobre quando o parser quebra no domingo de geração. Usuários de macOS tentam compartilhar .dmg e não conseguem porque o MIME type não tá no seed. O Marvin abre todo comentário com “Ah,” e você só percebe quando lê 30 seguidos e quer arrancar os olhos. O modelo LLM precisa ser trocável com 1 linha de config, mas tá espalhado em 24 arquivos. Windows usa UNC paths que começam com \\?\, e o CI explode na sua cara. E o TTS em modo “Auto”? Gera um sotaque que parece português de Lisboa tentando ser carioca.

Nada disso é “debugar” no sentido tradicional. É navegar um espaço de problemas que só se revela quando o software encontra a realidade. Cada um desses foi uma decisão tomada em tempo real por alguém com contexto.

A fantasia do one-shot prompt é que, se você escrever uma especificação suficientemente detalhada, a IA produz o software perfeito. Mas a especificação perfeita exigiria que você soubesse de antemão tudo que vai dar errado. E se você soubesse de antemão tudo que vai dar errado, você não precisaria da especificação — já teria o software pronto na cabeça.

Software bom é o resultado de centenas de micro-decisões tomadas com o sistema rodando. Não de uma macro-decisão tomada antes de escrever a primeira linha.

O Papel do Desenvolvedor Experiente

A IA acelerou tudo isso. Sem ela, 692 commits em um mês seria impossível pra uma pessoa só. Mas aceleração sem direção é só entropia mais rápida.

Em cada projeto houve decisões que a IA não teria como tomar sozinha. Trocar de Claude pra Grok-4 porque o modelo anterior tava fraco num domínio específico. Benchmark de SCRFD vs alternativas antes de implementar face detection, porque a escolha errada ia custar dias. O hardening de +163 linhas que eu commitei imediatamente depois de mergear o PR do Omarchy, porque eu vi onde ia quebrar. O revert do TTS em modo Auto no mesmo dia, porque eu sei que “Auto” num modelo de TTS pra português brasileiro vai produzir sotaque misturado.

O caso do circuit breaker é o mais ilustrativo. Quando adicionei rate limiting, a Brave Search API começou a retornar 429 de vez em quando. Se eu pedisse, o agente implementaria um retry com backoff exponencial. Mas eu não pedi retry. Pedi circuit breaker:

class WebSearcher
  CIRCUIT_BREAKER_SECONDS = 120

  def self.search(query, max_results: 5)
    return [] if circuit_open?

    response = brave_search(query, max_results)

    if response.code == 429
      trip_circuit!
      Rails.logger.warn("WebSearcher rate limited (429)")
      return []
    end
  rescue Net::OpenTimeout, Net::ReadTimeout => e
    trip_circuit!
    []
  end
end

Se a API retorna 429 ou timeout, para de tentar por 120 segundos. Sem retry, sem backoff, sem fila. Por quê? Porque eu sei que o cron roda todo dia às 8h e que nos domingos de geração de newsletter o volume de queries triplica. Uma manada de retries atrasando tudo é pior que resultados vazios numa seção.

A IA implementa um circuit breaker quando você pede. Mas ela não vai pedir pra implementar um circuit breaker. Ela não tem o contexto operacional. Isso é conhecimento que vem de rodar sistemas em produção por décadas.

O agente escreve o código. Eu decido qual código escrever. E essa decisão exige experiência que nenhum prompt substitui.

As Lições

1. Software em produção diverge da spec em horas, não em meses. Os primeiros bugs do M.Akita Chronicles surgiram na primeira newsletter real. Os MIME types do FrankMega quebraram nos primeiros uploads. Quem acha que deploya e acabou tá vivendo num mundo que não existe.

2. Pós-produção não é “manutenção”. 56 commits em 10 dias no M.Akita Chronicles não são patches. São features novas (Steam Gaming, preview, moods), refactoring de arquitetura (centralização de config do LLM), hardening de segurança (rate limiting). Isso é desenvolvimento. O software não parou de evoluir só porque eu disse “done” num blog post.

3. TDD protege a evolução. 99 novos testes em 10 dias. Os 1.804 testes do FrankMD permitiram mergear 4 PRs de contribuidores externos sem medo. Sem testes, cada merge é roleta russa.

4. Small releases mantêm a sanidade. 7 releases do Frank Sherlock em 7 dias. CI verde, binários compilados, release notes. Deu problema? Reverte uma versão. Compara com “6 meses + big bang release” e me conta qual funciona melhor.

5. Comunidade aparece pra projetos reais. Ninguém manda PR pra protótipo sem testes que “funciona na minha máquina”. O FrankMD recebeu 3 contribuidores porque tem CI verde, documentação, e releases versionados.

6. A experiência do desenvolvedor é o gargalo, não a velocidade da IA. 692 commits em um mês. Mas cada commit que importa exigiu décadas de experiência pra saber que era necessário. A IA digita rápido. Eu sei o que digitar.

7. One-shot é pra demo. Iteração é pra produção. Se o objetivo é um vídeo de 10 minutos mostrando um “SaaS pronto”, one-shot serve. Se o objetivo é software que sobrevive ao contato com usuários reais, só iteração funciona. E iteração sustentável exige disciplina: TDD, CI, small releases, refactoring contínuo. Sem atalho.

Pro Sênior que Ainda Tá de Braços Cruzados

Até aqui eu bati nos amadores que acham que podem mandar um prompt e a IA cospe um sistema pronto. Justo. Mas tem um outro grupo que me preocupa tanto quanto: o desenvolvedor sênior que viu a IA errar três vezes, declarou que “isso não serve pra nada”, e voltou a fazer tudo na mão.

Eu entendo o raciocínio. A IA alucina, gera código com bugs sutis, sugere soluções over-engineered. Tudo verdade, e eu documentei cada um desses problemas nos posts anteriores. Mas me diz uma coisa: você nunca fez exatamente a mesma coisa? Você nunca passou 2 horas lendo documentação pra descobrir que era um typo na config? A diferença é que quando a IA erra, você pega nos testes e corrige em minutos. Quando você erra sozinho, leva o mesmo tempo pra cometer o erro e mais tempo ainda pra achar, porque você confia no próprio código.

Vamos olhar pros números concretos do que eu entreguei em fevereiro, uma pessoa e um agente de IA:

Agora faz a conta de cabeça. Quanto tempo você levaria pra fazer o Frank Sherlock sozinho? Um app Tauri do zero, com pipeline de classificação por LLM em Rust, OCR via Python, full-text search com FTS5, detecção de duplicatas por perceptual hash, face detection com ONNX nativo, suporte a vídeo com extração de keyframe, CI pra 3 plataformas com code signing e notarização no macOS, auto-update, e publicação automática no AUR. Com 621 testes. Em Rust, que não perdoa.

Sendo honesto: sem IA, um dev sênior bom levaria no mínimo 3-4 semanas nisso, provavelmente mais. Eu fiz em 7 dias, sozinho, e cada release tá publicado com binários que qualquer pessoa pode baixar e instalar.

O M.Akita Chronicles eu já estimei no post anterior: ~200 user stories. Em Scrum com equipe sênior de 2-3 devs, sem impedimentos, seriam 10-15 semanas. Fiz em 8 dias. Hoje, 3 semanas depois, o sistema continua rodando, evoluindo, com 99 testes a mais do que quando “acabou”.

O FrankMega é mais modesto, mas file sharing seguro com Rails 8, I18n em 2 idiomas, 22 issues de segurança corrigidos, deploy via Docker, 210 testes. Fiz em 1 dia. Um sênior bom, sem IA, faria em 1-2 semanas na melhor das hipóteses.

E não estou falando de protótipos descartáveis. Gente de fora manda PR pro FrankMD. Assinantes reais recebem a newsletter do M.Akita Chronicles toda segunda-feira. Qualquer pessoa pode baixar o Frank Sherlock no GitHub Releases ou no AUR. CI verde, Brakeman zerado, testes reais, deploys automatizados. Isso é software de produção, não demo de conferência.

“Ah, mas eu faço código melhor sem IA.” Talvez. Mas em quanto tempo? O que eu mostrei aqui não é que a IA faz código perfeito. Longe disso. É que com TDD, CI, pair programming com agente, e refactoring contínuo, o resultado final é código de produção com qualidade. 4.057 testes estão lá pra provar. Brakeman zerado. 125 commits de pós-produção mostram que o código aguenta evolução sem virar uma bola de lama.

E usar IA de vez em quando pra gerar um trecho de código aqui e ali, tipo autocomplete glorificado, também não é a resposta. Você tá deixando 90% do ganho na mesa. O que eu fiz em fevereiro foi pair programming full-time com um agente. Do primeiro commit ao deploy em produção. Com a mesma disciplina que eu usaria com um par humano. Resultado: 4 projetos em produção em 1 mês, com qualidade que eu coloco meu nome. Porque eu coloquei.

Se você é sênior e ainda tá esperando a IA “melhorar” pra começar a usar de verdade, eu digo o seguinte: ela já tá boa o suficiente. Os 692 commits estão aí pra provar. O gargalo agora é você aprender a trabalhar com ela.

Conclusão

Em fevereiro de 2026, eu construí 4 projetos do zero à produção com IA. Mas a construção é a parte fácil. O que separa software de verdade de demo são os 125 commits que vieram depois, quando os bugs que ninguém previu apareceram, quando contribuidores externos mandaram PRs que precisaram de hardening, quando features novas surgiram do uso real e não de uma planilha de requisitos.

A IA me tornou absurdamente mais produtivo. Sem ela, o Frank Sherlock não teria face detection em 7 dias. Sem ela, o M.Akita Chronicles não estaria na 3ª semana de operação com 1.422 testes. A velocidade é real.

Mas nenhuma das decisões que importam veio da IA. Trocar de modelo, revertar o TTS no mesmo dia, olhar pro PR do contribuidor e ver que ia quebrar, pedir circuit breaker ao invés de retry. Tudo isso fui eu. A IA executou. As decisões foram minhas.

A IA é o acelerador. As técnicas de Extreme Programming (TDD, small releases, pair programming, refactoring contínuo) são o freio e a direção. Sem disciplina, IA produz código rápido que acumula dívida técnica mais rápido ainda. Com disciplina, IA produz software que evolui de verdade, semana após semana.

692 commits. 4.057 testes. 4 projetos em produção. E amanhã, segunda-feira, às 7h, os assinantes do The M.Akita Chronicles recebem a 3ª newsletter. Gerada, revisada, e enviada por um sistema que nunca vai estar “pronto”. Porque software pronto é software morto.

“Software pronto é software morto. Software vivo itera.”

“IAs NUNCA vão substituir NENHUM programador”

E isso está errado. Assista ao vídeo com a explicação (ou procure a transcrição). Mas em resumo, o que eu disse foi:

“IAs nunca vão substituir programadores COMO EU - EU nunca vou ser substituído”

Outra coisa que afirmei e continuo a afirmar é:

“AGIs não são possíveis na arquitetura atual: não vai acontecer. Precisa vir uma nova descoberta — que, obviamente, ainda não sabemos qual — pra ultrapassar a barreira atual, que é intransponível.

E foi disso que eu derivei esta frase:

“Sua empolgação com IA é inversamente proporcional ao seu conhecimento sobre IA” — e isso continua valendo igual.

A Bolha de Programação já estourou

Meu canal começou em 2018 e durou até o início de 2024, com um único propósito:

Ajudar a preparar programadores de verdade para sobreviverem ao estouro iminente da bolha (que se iniciou por volta de 2014).

Tenho uma playlist inteira intitulada EU AVISEI.

Em resumo, nos anos recentes, “programação” se tornou a “profissão do futuro”, e parecia fácil. Ficou óbvio quando o que mais se via era propaganda de todo tipo de curso e bootcamp, com promessas como: “vire programador em 2 meses, ganhe salário de Google e nem precisa trabalhar muito.”

Eu chamei esse tipo de programador de “chef de Miojo”. Só porque você sabe esquentar água e fazer miojo, isso não te torna um chef. Deveria ser óbvio, mas é como a programação era vista. Nenhum desses cursos formou nenhum “programador”, muito menos “engenheiro de software”.

Mas “engenheiro de software” não é uma engenharia de verdade. Não existe um CREA, CRM, OAB, nada equivalente que certifique alguém como “engenheiro de software”. Isso é um título inventado que qualquer pessoa pode colocar no LinkedIn.

O Cisne Negro da Pandemia foi algo que eu não previ, mas isso só ajudou a inflar ainda mais a fase final da bolha, que estourou no fim de 2022 quando se iniciaram layoffs em massa em todas as big techs. E isso foi ANTES do advento das LLMs pra programação. Por coincidência, ChatGPT surgiu na mesma época em 2022, mas essa não foi a causa; foi só o último prego no caixão. O estouro daquela bolha e os layoffs viriam de qualquer forma.

Por isso, meu canal deve ser o único que, ainda hoje, oferece os conteúdos de que alguém que realmente pensa em ser programador precisa. Imagina os outros canais que só propagandearam que virar programador era fácil, envelheceram BEM mal.

Portanto, sim, concordo com o CEO da Anthropic: esses “engenheiros de software” se tornarão completamente obsoletos. Não existe virar “engenheiro” em um bootcamp de 1 mês. Isso era bullshit e tinha que ser muito idiota pra acreditar. Notem que todos esses vendedores de óleo de cobra SUMIRAM. Cadê eles?

Não sabe por onde começar no meu canal? Duas sugestões:

• Playlist “Que cursos devo fazer?”
• Playlist “Carreira”

O “teto” das IAs

Eu terminei de gravar vídeos pro meu canal exatamente quando começou essa onda de IAs. Considerei que tudo o que queria dizer já foi dito e isso continua disponível no canal. Meu objetivo foi atingido.

Durante 2024 e 2025 eu participei de podcasts como Flow e Inteligência Ltda falando muito sobre IAs e coisas como computação quântica (e como também é só um hype que não vai em nada prático pro nosso dia a dia).

O principal: desde o paper sobre transformers Attention is all you need, ainda não surgiu nenhum outro “breakthrough” que ultrapasse esse marco. Tudo o que temos hoje, de OpenAI à Anthropic, e de open sources como DeepSeek, Qwen3, GLM, MiniMax etc., se baseia exatamente na mesma fundação, na mesma “arquitetura”.

E eu teorizei - corretamente - que a evolução dessa arquitetura obedeceria a uma Curva em S:

GPT-1 para o 2 foi um salto quântico. GPT-2 para o 3 foi um salto gigante. GPT-3 para o 4 foi excelente, mas, notavelmente, não na mesma proporção. GPT-4 para o 5, a maioria das pessoas comuns nem notou tanta diferença.

Claro, ninguém ficou parado; todo cientista da computação, matemático, engenheiro foi fazendo o que sempre fazemos: otimizando. Surgiram melhores formas de treinar, a ideia de “reasoning”, a ideia de agentes trabalhando em conjunto (um dando feedback pro outro), novas formas de alinhamento e de instrução. Mas nada disso altera a arquitetura da fundação.

O problema: pra treinar cada nova geração de LLMs, fica consideravelmente mais caro (em hardware e, principalmente, no consumo de energia) pra gerar uma versão que não é muito melhor que a anterior. Esse é o teto da curva. E eu reafirmo: enquanto não surgir uma NOVA ARQUITETURA, vamos só chegar cada vez mais perto desse teto, sem ultrapassá-la, mas gastando níveis absurdos de mais memória e mais energia.

Por isso, está faltando energia: com o aumento da demanda de uso (inferência), eles têm que se dividir entre gastar energia pra treinar novas versões e atender à demanda. Não dá pra fazer os dois.

Pior, por isso, a memória RAM explodiu em preço e seu PC também vai ficar muito mais caro. Não tem mais recursos pra treinar modelos tão grandes que, proporcionalmente, oferecem cada vez menos resultado (definição de “diminishing returns”). É o destino de toda inovação: bater no teto da curva em S até surgir outra que a substitua.

O foco agora está em usar melhor as versões que já temos. No caso de programação, surgem GPT Codex ou Claude Code, que são estratégias de uso de agentes, MCPs, skills e outras ferramentas e formas de orquestração pra extrair o máximo do que já temos hoje.

Estratégias das LLMs

Todo mundo já sabe que é impossível só fazer um prompt e que qualquer LLM saia com um sistema perfeito no final. Vai sair muito ruim; continua assim e vai continuar assim nesta arquitetura.

Toda LLM tem um limite de contexto (memória). É impossível carregar todo o código-fonte de um ERP gigante como o da Totus ou o da SAP. Não cabe, e mesmo se coubesse, não seria possível dar “atenção” a tudo. Existem limites: quanto mais memória você coloca, pior fica a inferência; o resultado fica pior. Como tudo em software, é um “trade-off”.

Em vez disso, o melhor é criar scripts que percorrem seu código e extraem pedaços específicos a cada execução. Se estiver mexendo no carrinho de compras, não precisa carregar código que lida com a tela inicial da loja, por exemplo. É parecido com o que um programador humano faria: dividir pra conquistar (como diria Napoleão).

Toda LLM específica pra código, como Codex ou Opus, foi treinada pra fazer “tool calling”, que é enviar um pedido ao “chat” pra que ele busque informações (como código) e carregue trechos no contexto. Pra isso, ele manda executar ferramentas como “rg” ripgrep (no caso do Codex) ou “grep” (no caso do OpenCode).

Se, por acaso, o modelo não foi treinado com informações que só saíram recentemente na Web, ele pode fazer “agentic fetch”, que é executar comandos como “curl” pra, literalmente, ir no Google, no Stack Overflow, etc., e puxar as páginas web pra usar como parte do contexto (o trade-off é que isso vai usar o espaço limitado de contexto).

Quando o contexto está prestes a acabar (a faixa de 200 mil tokens, no caso de um Claude, ou 1 milhão, no caso de um Gemini), o “chat” que orquestra (Claude Code, OpenCode, etc.) manda gerar um resumo do contexto atual, pra “compactar” o entendimento e reiniciar com um novo contexto com base nesse resumo.

Pra garantir que o código gerado “funcione”, o tool calling pede pra rodar ferramentas locais, como linters, compiladores ou LSPs (como uma IDE, como o VSCode, faria). Isso gera feedback (e gasta mais contexto). Se errar, o “chat” pode pedir automaticamente pra refazer, levando essa nova informação em consideração.

Além disso, pra ir “mais rápido”, o “chat” pode mandar executar vários agentes em paralelo. Cada agente é um novo contexto - e nada disso é de graça, lembrem-se: tokens por segundo. Então, poderia mandar um agente vasculhar todo o código relevante ao banco de dados e, no final, gerar um resumo. Outro agente vasculha todo o código de pagamentos e, ao final, gera um resumo. Outro agente vasculha o código relevante ao front-end do carrinho e gera um resumo. Então o “chat” pega esses resumos e volta ao contexto anterior pra executar alguma tarefa.

O que chamo de “chat” é só pra ficar mais fácil de visualizar. Pense na interface simples de chat que todo mundo usa no dia a dia, mas com recursos adicionais. Isso é o que faz um Codex ou um Claude Code. Não tem segredo nenhum, toda ferramenta dessas, assim como as open source como Opencode ou Crush, fazem a mesma coisa: configuram um “Harness”:

• Iniciam com um prompt de sistema detalhando exatamente como quer que a LLM responda. Este GitHub tem vários exemplos desses prompts que a ferramenta envia sem você saber.
• As LLMs são treinadas com tool calling e a ferramenta sabe como responder a essas chamadas (executando bash, curl, ripgrep, sed, diff, git, etc)
• A ferramenta é capaz de executar múltiplos agentes em paralelo (pense múltiplos “chats” em paralelo)
• A ferramenta pede pra LLM gerar um “plano” primeiro e enumerar tarefas. Daí ela pode orquestrar a execução sequencial dessas tarefas, cada uma em um agente diferente, por exemplo.
• A ferramenta é capaz de gerenciar os limites de contexto e saber quando mandar resumir, e como reiniciar um novo contexto e continuar a execução das tarefas restantes
• A ferramenta é responsável por criar um contêiner e evitar que comandos malfeitos afetem seu sistema (isso é opcional; nem todos fazem ou não ligam por padrão. Cuidado!)

Eu documentei sobre isso em vários posts neste blog:

• Hello World de LLM: criando seu próprio chat de I.A. que roda local
• Rant - LLMs vão evoluir pra sempre? Desmistificando LLMs na programação
• Quando LLMs não Funcionam pra Programar? Um caso de uso mais real.
• AI Agents: Garantindo a Proteção do seu Sistema
• AI Agents: Comparando as principais LLM de 2026 no Desafio de Zig
• AI Agents: Instalando LSPs pro Crush
• AI Agents: Qual é o melhor? OpenCode, Crush, Claude Code, GPT Codex, Copilot, Cursor, Windsurf, Antigravity?
• Vibe Code: Eu fiz um appzinho 100% com GLM 4.7 (TV Clipboard)
• Vibe Code: Qual LLM é a MELHOR?? Vamos falar a REAL
• Vibe Code: Fiz um Editor de Markdown do zero com Claude Code (FrankMD) PARTE 1
• Vibe Code: Fiz um Editor de Markdown do zero com Claude Code (FrankMD) PARTE 2

O Fim do Stack Overflow

Na época do GPT-3 e do GPT-4, eu já fazia códigos usando LLMs e funcionava bem. Mas eles ainda tinham muitas chatices. As alucinações eram muito frequentes. Tinha muito “agentic loop” (quando a LLM “acha” que já consertou, mas não consertou e fica em loop, sem saber o que fazer). A atenção ao contexto era facilmente perdida (melhorou muito com a Flash attention). Enfim, vários problemas mais “grosseiros” já foram ajustados a ponto de não aparecerem mais com tanta frequência. Não é “resolvido”; ainda acontece, mas cada vez está melhorando.

Quanto mais se aprimoraram os dados de treinamento e o alinhamento, mais esses problemas desapareceram. O problema é que já chegamos ao ponto em que acabaram os dados de treinamento no mundo. Tudo o que poderia ser usado já foi. Não é só falta de energia e de hardware. Acabou a informação pra treinar.

A solução foi massagear os dados existentes pra extrair o máximo possível e adicionar muitos dados sintéticos (gerados pela própria IA). De novo, isso já bate num teto de “diminishing returns”.

Além disso, vários sites usados pra extrair dados pra treinar as LLMs estão caindo em desuso. O exemplo mais notável é o venerável Stack Overflow. Vejam como caiu o tráfego.

Alguns desavisados poderiam só pensar: “ah, tudo bem, o povo passou a fazer pergunta idiota pras LLMs, acabou aquele monte de gente postando pergunta básica nos fóruns.”

É verdade, parece um avanço. Mas até “pergunta idiota” é um dado relevante de treinamento. Se a LLM “vê” que certos assuntos têm maior probabilidade, quando ela receber a mesma pergunta, “tende” a dar a resposta mais popular. Se esse dado desaparece, também desaparece a relevância de diversos novos assuntos. Agora, cada LLM vai depender de usar as perguntas feitas ao chat como novo dado de treinamento, só que a OpenAI só vai ter perguntas feitas pra ela, e ela não vai saber quais são as perguntas mais populares feitas no Claude, o que diminui cada vez mais as fontes de informação relevantes.

O que toda plataforma deve estar fazendo agora é coletar todas as perguntas que você faz a elas, todas as respostas que a LLM gerou, todo o feedback que você ou suas ferramentas dão sobre se foi sucesso ou erro, e vai acumulando isso pra usar pra treinar a próxima versão, o GPT-6 ou o Sonnet-5. Vamos ver o quanto dá pra evoluir só com isso — lembrando que o “volume” de informação não se iguala à “qualidade” pro treinamento. Esse ainda é o calcanhar de Aquiles.

O ponto é: pelo menos temporariamente, a maior parte dos dados relevantes na Web acabou, e estamos produzindo menos do que antes.

Restrição == Inovação

Sim, eu também acredito que uma categoria inteira, que se autointitulava “engenheiro de software”, vai deixar de existir por causa das IAs.

Não vai mais existir aquela “especialização” esquisita de “front-end que não mexe em nada de back-end” ou de “back-end que não mexe em nada de infra”. Front-end, em particular, é o mais fácil de substituir, pois era um grande volume de código de baixo valor agregado, com muita duplicação. Não era difícil automatizar, mas ninguém queria: era mais “legal” ficar inventando novos frameworks toda semana que fazem a mesma coisa, com formas levemente diferentes. Finalmente acabou essa palhaçada.

Palestrei anos sobre Restrição == Inovação e como inovação não acontece quando se tem dinheiro sobrando, que foi o que aconteceu na última Bolha de Programação: pra que automatizar as coisas, ser eficiente, se tem dinheiro sobrando, é só contratar mais e mais gente pra fazer coisas mais e mais simples e braçais?

Na Bolha da Internet, havia tanto dinheiro sobrando que existia a profissão de “catalogador de sites”: gente que ficava o dia inteiro digitando manualmente todos os novos sites que surgiam na recém-lançada Web. Levou anos até surgirem um Altavista e, depois, um Google, que descobriram como automatizar isso. Antigamente, não existiam “admins” web pra publicar novos produtos num e-commerce: alguém editava o HTML da página principal do Submarino.com todos os dias, com novas ofertas. Tudo trabalho de alto volume e baixo valor agregado. Automatizamos tudo isso e, agora, com LLMs, só fomos um passo à frente.

Mesmo antes de LLMs, não fazia sentido precisar de gente exclusivamente pra ficar fazendo HTML/CSS descartáveis o dia todo. As ferramentas um pouco mais automáticas, como um SquareSpace.com da vida, não eram tão boas.

O problema é o seguinte: algo simples, como um “Web Admin” pra editar conteúdo sem precisar saber HTML, nos anos 90, não existia. Alguém precisou criar as primeiras versões desse tipo de software pra entendermos o que funciona e o que não funciona. Quem era dos anos 90 vai se lembrar de softwares comerciais caros como o famoso Vignette Story Server. Hoje em dia, qualquer Wordpress open source faz a mesma coisa melhor.

Ninguém se lembra de software e de empresas que não existem mais. Especialmente jovens, acham que o mundo já apareceu com a Web pronta, com redes sociais prontas e plataformas de e-commerce prontas. A sensação deve ser que, no Egito Antigo, o povo já comprava na Amazon, pedia delivery no iFood e todo mundo se comunicava pelo Whatsapp. Eu fiz um video chamado A Dimensão do Tempo, Minha Máquina do Tempo e Meus Primeiros Cinco Anos pra tentar dar um pouco de perspectiva sobre isso.

O ponto é: tudo o que as LLMs sabem fazer já existe ou já existiu.

Eles não são capazes de inventar seja lá o que for, seja a “Vignette dos anos 2030” ou o “Instagram dos anos 2030”. E não digo isso no sentido do “próximo gerenciador de conteúdo” ou “próxima rede social”. Eu digo no sentido de que “rede social” era um termo que não existia nos anos 2000 e “gerenciador de conteúdo” não existia nos anos 80, por exemplo. O que é a nova categoria que vai aparecer nos anos 2030?

Não sei; se eu soubesse, obviamente estaria construindo pra lançar e ficar bilionário. Ninguém sabe, muito menos LLMs. Elas conseguem derivar muitas coisas do treinamento, mas o que não está nas probabilidades do modelo não vai “espontaneamente” aparecer”. Não é assim que IAs funcionam.

Podemos ficar pra sempre só refazendo tudo o que já foi feito igual já existe hoje. Mas não muito mais do que isso. Mas o ponto das minhas palestras foi justamente que somente com muito dinheiro e muita força bruta, não nascem inovações.

Programadores na Era das LLMs

A conclusão é muito simples: programadores como eu sempre vão existir. O que sempre deixa de existir são profissões que só têm volume, mas baixo valor agregado. Esse é o conceito.

Como disse nos meus videos, durante minha carreira eu já sobrevivi ao fim da bolha dos microcomputadores no começo ao meio dos anos 90, a bolha da internet do meio dos anos 90 até o começo dos 2000, a recessão de programação de 2001 a 2008, a bolha financeira imobiliária que estourou em 2008 mas deu origem à bolha da programação, principalmente dos anos 2014 até 2022, e agora a bolha de IAs.

Não se enganem: é sempre assim, e esse é nada mais do que um episódio.

Quem é o programador que sobrevive a todas essas bolhas? Este:

O teto das LLMs já está aqui e o que elas estão entregando agora não vai mudar muito: o processo vai ser o mesmo. Vai ficar um pouco mais rápido. Vai gerar um pouco menos de erros e pequenos ajustes assim. Mas o processo vai continuar igual até aparecer alguma nova arquitetura ou alguma nova descoberta que ainda não sabemos.

Nenhum código gerado por IA vai ser automaticamente perfeito pra ser colocado em produção sem nenhum tipo de revisão ou intervenção humana. - Qualquer um que ache o contrário ou que não testou nenhuma LLM na prática ou nunca trabalhou em projetos de verdade.

Como disse no Flow, esta é a SEGUNDA Bolha de IAs. A primeira foi nos anos 60 por causa do inventor de redes neurais, Frank Rosenblatt. Assim como o Sam Altman ou o Dario Amodel, ele também fez MUITO hype sobre redes neurais e computadores que iriam ficar muito mais inteligentes do que seres humanos “muito em breve”, e todo jornal da época publicou sobre isso. As promessas morreram como promessas e isso gerou o “Inverno das IAs” nos anos 70, onde muito investimento foi feito, o resultado não foi proporcional, e pesquisas sobre IA estagnaram pelas décadas seguintes, andando a passos de tartaruga.

Isso só começou a mudar mesmo com o advento e a popularização da Web, o surgimento de redes sociais, o surgimento de Big Data e, agora, com volumes grandes de dados pra iniciar uma nova era de pesquisa em redes neurais, com muito mais material de treinamento. E agora com a existência de GPUs pra acelerar o processamento. Foi quando surgiu a AlexNet, de George Hinton, Yann LeCunn e Ilya Sutskever, o “breakthrough” das convolutional neural networks (CNNs) e da paralelização de processamento via GPUs.

Sem isso, não se evoluiria pra transformers, difusores e coisas como Nano Banana e Sora. Esse é um tipo de área em que LLMs não vão contribuir: pesquisa de ponta e novas descobertas. Nesse campo vão continuar sendo necessários cientistas da computação, matemáticos, físicos teóricos, etc. Se você tem vocação pra pesquisa, ainda vai ser uma área fértil por muitos anos. A régua só subiu, o que é bom.

Sobre o Claude que conseguiu fazer um compilador de C:

O compilador de C é o mais fácil de fazer; é literalmente matéria de faculdade, porque C é uma das linguagens mais “simples” (começou como macros de Assembly).

Como o próprio artigo da Anthropic — que ninguém leu, lógico — diz, eles usaram o GCC pra comparar.

Claro, GCC existe; é o compilador principal pra compilar o kernel do Linux. Se você copiar o GCC, vai chegar em outro GCC, não importa em que outra linguagem escrever — essa não é a parte difícil, porque toda linguagem consegue fazer tudo o que outra linguagem faz (todas são Turing Complete: pode ser mais lenta, pode ser mais insegura, pode dar mais trabalho, mas eu posso fazer um compilador de C em Visual Basic, se eu quiser, não é impressionante).

Nenhuma LLM substituiu o Linus Torvalds, nem Richard Stallman, nem nenhum dos grandes programadores cujos nomes você já ouviu falar. Eles conseguem copiar o que já foi feito e só. Sim, eles são “stochastic parrots” (papagaios estocásticos), independentemente do que um George Hinton tente propagandear a seu favor (todos têm vieses). Aliás, como eu já disse nos podcasts: foda-se George Hinton. Parem de cair na Falácia do Apelo à Autoridade.

Recado às Empresas

Isso deveria ser óbvio, mas vou deixar registrado só pra poder dizer “EU AVISEI” depois.

• Nenhuma LLM vai escrever código sozinha. Precisa de um sênior pra especificar.
• Todo código gerado por LLMs precisa de revisão. Precisa de um sênior pra revisar.
• Uma parte do código gerado precisa ser reescrita. Precisa de um sênior pra saber.
• Outra parte do código vai ter bugs que a LLM vai deixar passar. Precisa de um sênior pra saber.
• Sabendo quais são esses bugs, dá pra LLM consertar.

Isso dito, algumas coisas que LLMs fazem muito bem:

• Análise exploratória de código legado
• Refatorar partes de código legado
• Adicionar testes unitários em partes de código legado
• Sugerir melhorias em partes de código legado
• Achar alguns buracos de segurança ou performance em código legado

Note como eu digo “partes” ou “alguns”. Não há garantia de que ele consiga fazer isso em qualquer legado ou parte. Novamente, precisa de um bom sênior avaliando cada passo.

Tudo é feito PASSO A PASSO. Uma tentativa, uma checagem, um ajuste, repita. É o famoso ciclo PDCA: Plan, Do, Check, Act. Esse é o processo que funciona. Cada novo ajuste testado vira um “git commit” e vamos ao próximo passo. Sempre um passo de cada vez, sistematicamente, organizadamente. Nunca algo genérico como “Conserte tudo neste sistema legado”.

Outra coisa em que LLMs são muito boas é reescrever código de uma linguagem para outra (traduções em geral). Mas não recomendo e nem é só por ser LLM:

Eu nunca recomendo reescrever do zero como primeira opção.

Não existe garantia de que uma linguagem mais nova seja “melhor” do que uma mais antiga. O “melhor” sempre “depende” da sua definição de “melhor”.

Está na moda essa ideia de reescrever tudo em Rust porque teria menos problemas de segurança. Isso é incorreto. Rust é bom para algumas categorias de segurança, mas não pra todas. E existe toda uma categoria de problemas funcionais que não aparecem em nenhum compilador. Reescrever algo complexo, como um kernel do Linux, em Rust é uma ilusão e uma inutilidade enormes. Se “parece fácil” fazer uma LLM reescrever em Rust, é igualmente fácil ela consertar pontualmente um errinho em C também, sem mexer no resto que já funciona.

Reescrever é, sim, garantia de que vários novos bugs vão surgir e você não vai detectá-los imediatamente; vai ser uma nova bomba-relógio. Pra consertar um bug conhecido, você acabou criando vários outros bugs desconhecidos. Reescrever, por definição, sempre vai adicionar novos bugs.

E não, quando se pede pra LLM: “encontre todos os bugs de segurança neste código”, ele vai encontrar alguns, mas nunca todos.

Entenda o português: ele sempre vai dizer algo como “Eis todos os bugs que descobri…” Até a LLM hoje em dia não vai mais tentar dizer “Eis todos os bugs que existem”.

Nenhuma IA é feita pra dar respostas 100% corretas e sem ambiguidade. Pelo contrário, é sempre uma máquina probabilística que vai dar a resposta com base nas probabilidades do modelo gerado pelo treinamento. O que não estiver nesse modelo, ele não sabe. E, mesmo dando contexto, não há garantias de “entendimento completo”, e sim de “algum entendimento”. Sempre trabalhe com probabilidades inferiores a 100%.

Linguagens de programação, por sua própria natureza, não são determinísticas. Não existe nenhuma forma de escrever uma equação matemática em que eu possa passar o programa e ele garanta a ausência de bugs. Isso é uma impossibilidade matemática; não é “questão de tempo”. O tempo não tem nenhuma relevância nessa definição.

A detecção de bugs (funcionais, de segurança, de performance, etc.) é sempre um processo estocástico, uma heurística, nunca um algoritmo. Isso é algo que todo cientista da computação ou matemático entende, mas ninguém que nunca estudou consegue entender. Para pessoas comuns, heurística é a mesma coisa que algoritmo. Esse é um erro que pode ser fatal.

Então, toda LLM, por sua própria fundação e arquitetura, sempre vai ter essas e outras limitações embutidas. Mas isso não é um problema, é apenas a natureza da ferramenta. Martelos não servem pra girar parafusos, e isso não é um defeito. Deveria ser óbvio, mas bater um martelo num prego e não girar é uma característica natural. Não é nem uma vantagem nem um defeito. Depende de qual problema quer resolver.

No geral, LLMs vão ser muito boas em lidar com trabalhos braçais: adicionar testes, refatorar código, ajustar front-end, criar telas novas a partir de telas antigas, criar relatórios novos a partir de relatórios antigos. Criar tradução do português para o espanhol das telas do seu sistema. Pra esse tipo de prego, LLMs são o martelo perfeito.

Agora, interpretação exata de leis, regras de negócio, casos individuais e exceções à regra, flexibilização de certas regras — tudo o que faz parte das tomadas de decisão numa empresa. Nunca confie totalmente em nenhuma LLM: vai precisar de um humano experiente pra aprovar ou rejeitar. Por mais que ele tenha memorizado todas as leis do país, não há garantia de que saiba quando usar ou não usar, e como isso pode variar nos mais variados casos, especialmente nas exceções.

Nunca pergunte a um martelo como você deve dirigir sua empresa.

“Como ter sênior se não vai mais ter júnior?”

Notem que a premissa é que, no mínimo, sempre vão precisar de um sênior instruindo e revisando o trabalho das LLMs.

Mas se as LLMs conseguirem executar todas as tarefas braçais que antes eram destinadas aos estagiários e júniors, como vão crescer pra virar sênior?

É a pergunta de 1 bilhão de dólares e já adianto que eu não sei a resposta inteira. Ninguém sabe.

O início é fácil. É como eu disse em todos os vídeos do canal: é como fiz minha carreira inteira: ter uma boa formação e “aprender a aprender” de verdade. Mais fácil falar do que fazer; por isso, levei 5 anos de vídeos tentando explicar dos mais variados jeitos pra ver se alguém entende.

A próxima parte que é difícil: como aprender se as LLMs já fazem tudo?

Essa pergunta parte de uma premissa errada: as LLMs não fazem tudo. Elas fazem o que for pedido. Se o pedido estiver bem especificado, vai sair um prato gourmet de um restaurante com 3 estrelas Michelin. Se o pedido for tosco, de alguém claramente inexperiente, vai sair um miojo. É assim, simples.

O resultado da LLM é diretamente proporcional ao trabalho de instrução, avaliação e acompanhamento do humano no controle.

“Como alguém vai ser programador se nem sabe como fazer pra perfurar um cartão?” - É uma pergunta justa se perguntar a alguém nos anos 60.

“Como alguém vai ser programador se nem sabe gravar numa fita cassete?” - É outra pergunta justa se for alguém dos anos 80.

“Como alguém vai ser programador se nem sabe editar código num editor de textos como Emacs e precisa de Eclipse?” - Outra pergunta justa, se for alguém dos anos 90.

“Como alguém vai ser programador se nem sabe programar pra Web?” - Uma boa pergunta pra alguém no começo dos anos 2000.

“Como alguém vai ser programador se sequer sabe fazer um app mobile?” - Se for alguém nos anos 2010.

¨Como alguém vai ser programador se tem LLMs?" - A pergunta dos anos 2020. Boa sorte.

Toda geração tem perguntas similares. Nenhuma tem uma solução exata. Veja os fatos: ainda estamos aqui. Em 2026, sei coisas de programação que nunca sonhava saber quando entrei na faculdade em 1995. Tudo mudou. Todo mundo que “aprendeu a aprender” soube se ADAPTAR e usar o conhecimento que já tinha pra aprender novas formas de trabalhar.

É tudo uma questão de adaptação: quem não se adapta é extinto. Essa é a lei.

Não tem muito mais a dizer a respeito disso. Mas na prática:

Se você é programador, use LLMs. Aprenda os pontos fortes e fracos, os diferentes resultados que ela obtém dependendo do seu próprio conhecimento, e nunca pare de estudar e treinar.

Se você é sênior/empresa, continue contratando júniores. Seus sêniores não são imortais. No mínimo, em uma hora eles vão se aposentar. Mais realista: uma hora eles vão mudar de emprego. A segunda tarefa mais importante de qualquer sênior é mentorar júniors e criar substitutos. Sênior incapaz de criar seu próprio substituto não é um sênior, é uma liability.

Mentorar é a mesma coisa de sempre: treinamento com acompanhamento e feedback, melhoria contínua, com a diferença de que, além de sistema operacional, editor de texto e IDEs, sistemas de CI, etc., agora tem LLM na caixa de ferramentas. É isso. Não tente complicar o que não precisa e não sofra por antecedência.

Conclusão

“Ain, mas você falou que a bolha das IAs vai estourar.”

Sim, e continuo dizendo. Mas você está entendendo errado, novamente. De 1994 a 2001 existiu a Bolha da Internet, e ela estourou!

Entenda: a “Bolha da Internet” estourou. Mas a “Internet” continua existindo até hoje. ¿Está claro?

Mesma coisa: a “Bolha das IAs” vai estourar, muitas empresas vão falir, muita gente da área vai perder o emprego, etc. Mas IAs vão continuar existindo. A bolha das IAs dos anos 60 estourou, mas as IAs continuaram existindo e até formaram uma nova bolha agora. Ciclo econômico não tem a ver com ciclo tecnológico.

Só quer dizer: “não aposte todas as fichas no mesmo cavalo, especialmente se sua vida/carreira depende disso.”

LLMs vão continuar existindo, aproximadamente no mesmo formato, um pouco mais rápidas e eficientes, mas com o mesmo processo por trás e a mesma forma de trabalhar. Assim como a Web de 2026 não é muito diferente da tecnologia dos anos 90, mas é mais refinada e otimizada.

Eu nunca fui “hater” de IA, pelo contrário, sou um que já arriscava fazer código com o GPT-2. E sempre está melhorando. Agora está num ponto em que é fácil recomendar até pra não-programadores brincarem com sistemas que não vão pra produção nem são de missão crítica.

Desde que comecei com programação, no fim dos anos 80, felizmente nunca tive um único momento em que achei nossa área “entediante” ou “monótona”. Pra mim, é só mais um capítulo nessa história, e eu tenho expectativa de novos capítulos.

O que eu falo que “parece hate” é só argumentação e explicação das limitações atuais e das expectativas irreais, ilusões ou até apostas cegas em que sei que não vão vingar. Estou avisando do que é real. Mas sempre estou dizendo: “precisa haver uma nova descoberta”. Com a expectativa de que algo mais vindo no futuro, e não de que “não vai dar nada certo”.

No final do dia, o Java dos anos 90 não substituiu o Cobol e o Fortran do mundo, como se pretendia. A Web não virou uma utopia pacífica de puro conhecimento como se queria. O mobile não substituiu outras formas de computação, como se queria. VR não se tornou a nova onda. Nada disso invalida as qualidades do Java, da Web, do Mobile ou até da VR.

A última Bolha da Programação foi um período entediante pra mim em termos de inovação: porque tudo era substituído por programadores baratos. Pra mim, o estouro dessa bolha era esperado e me deixa muito feliz. Porque finalmente saímos do marasmo de cursos idiotas pra falarmos de tecnologia de ponta de novo. Programadores voltando a ser programadores de verdade.

Só vejo coisas boas nisso.

Como podem ver, eu tenho praticamente todos os handhelds possíveis e imagináveis. Então acho que tenho alguma propriedade pra falar sobre as vantagens e desvantagens da maioria dos mais populares. E eu tinha mais, mas fui doando pra amigos com o tempo. Esses são os meus favoritos.

Vou falar dos hardwares primeiro e na segunda parte do artigo vou falar um pouco dos softwares também. Use os links de seção na direita (na versão desktop), pra navegar onde quer ler primeiro.

Já aviso que vou ser preguiçoso e nas tabelas de especificações, sim, é ChatGPT pra ajudar. Senão é muito detalhe kkkk 🤣

Ambernic RG400M

Especificações

Este é um dos mais antigos que eu ainda tenho. Ambernic é a marca que eu mais gosto e um dos mais confiáveis. De vez em quando lançam modelos esquisitos, mas no geral são bem consistentes na qualidade.

Esse modelo 400M acho que não existe mais, mas o sucessor dele é RG477M e recomendo assistir o review do canal Retro Game Corps:

Durante todo o artigo vou sempre linkar pros reviews desse canal porque considero que o Russ faz os reviews mais completos. Ele realmente vai fundo em cada detalhe, tamanho dos botões, peso, compatibilidade, tudo. É o único canal que você precisa assistir.

Pra 2025 o 400M/477M é antiquado, inclusive é caro, a USD 280, sem considerar frete e taxa bostil (que vai dobrar esse preço). Isso porque ele tem corpo de alumínio, o que dá uma sensação bem mais premium do que os baratos de plástico. Porém, eu acho que a maior desvantagem dele é que a resolução da tela é só 1280x960. Vou falar de resolução em outra seção, mas acho isso baixa resolução.

Quer dizer, pra jogar coisas como Gameboy, funciona super bem, mas se for pra Mega Drive, Super Nintendo, já começa a ficar apertado. Acima disso já sinto pixelizado mesmo numa tela pequena de 4.0".

O 477M tem tela maior, inclusive é isso que os nomes querem dizer: 400M tem tela de 4.0" e 477M tem tela de 4.7". O 400M tem SoC (System on a Chip) Unisoc T618 2.0Ghz e o 477M tem o MediaTek Dimensity 8300 3.35Ghz. Triplo de RAM (4G LDDDR4X vs 12GB LPDDR5), bateria um pouco maior (4.500 mAh vs 5.300 mAh).

Parece potente mas é porque esse handheld roda Android. Eu particularmente não curto handhelds Android. Depois falo porque.

No geral é um excelente handheld, pequeno, premium, roda bem até PS1 e dá pra arriscar um PSP, mas a tela não foi feita pra isso (PSP é widescreen, este é 4:3). Só que eu não recomendo ele é muito caro e a performance não condiz com o preço, só é caro porque é de alumínio. Pelo mesmo preço se compra outros muito melhores, como vou mostrar a seguir.

TRIUMUI BRICK - MIYOO MINI

Os próximos da lista são os verticais “miniatura”.

O mais clássico de todos é sem dúvida o Miyoo Mini Plus:

Falei que 4.0" e 1280x960 acho pequeno? O Miyoo Mini Plus tem tela de só 2.8" e resolução de 750x560. O SoC é muito bom com ARM Cortex-A7, 1.2Ghz que consegue rodar bem até PS1. Nessa tela pequena é mais indicado pra coisas como Gameboy, GameGear e outros portáteis antigos. Dá pra jogar NES, MasterSystem, MegaDrive. Mas PS1 já começa a ficar muito pequeno pra conseguir ler.

É difícil de descrever quão pequeno é essa tela. Compare acima a tela com meu dedão pra ter uma noção. É extremamente pequeno. Não recomendo pra nada muito maior que jogos de Gameboy mesmo. Se você for jovem, com boa vista, vai conseguir jogar melhor. E vai ficar com a vista ruim como a minha mais rápido também kkkk 🤣 fica pelo seu risco.

Eu uso óculos de muito grau, então essa tela é muito pequena pra mim. Mas a construção da Miyoo é muito boa. Ela tem aquela sensação de Gameboy clássico mesmo, só que em miniatura. O fator nostálgico é muito forte.

O melhor OS pra ela é o Onion OS, que torna o Miyoo ainda muito melhor. Uma coisa comum é que todo handheld vamos acabar substituindo o OS que vem por um open source melhor. É muito satisfatório a UI pra salvar estado do game, depois recarregar de onde parou.

De longe uma das melhores UIs pra handhelds. Todo OS deveria copiar o OnionOS. De novo, o review do Russ sobre ele é bem detalhado:

Depois do Miyoo Mini Plus, que considero “miniatura com tamanho suficiente” é o TrimUI Brick. Ele é parecido em formato e funcionalidades com o Ambernic RG35xx Plus então qualquer um dos dois vai atender quem quer esse tamanho.

A tela do TrimUI é consideravelmente melhor em qualidade, cores saturadas, mais nítido, mais brilhante. É uma das melhores telas nesse formato que existem. Não tem como errar. Comparado com o Miyoo Mini, veja a diferença de qualidade de tela e, principalmente o tamanho!

E veja como a área útil não é muito menor que a tela de um Gameboy Advance SP de verdade, por isso é bem jogável.

Pra melhorar, existem outros OS que dá pra instalar no TrimUI, como o lendário Knulli, mas você pode optar por pedir um microSD card já configurado e com vários jogos bons (não aquela lista genérica gigante de jogos repetidos que vem nos outros). Ele vem com o SurwishOS, que não é um OnionOS mas não está longe.

Ou seja, “out-of-the-box”, sem precisar configurar nada, o TrimUI Brick é um dos mais simples. Só ligar e já jogar, sem precisar mexer em OS ou fazer qualquer tuning. Plug and play. É fácil, um dos melhores que posso recomendar.

Novamente, roda bem até PS1, arrisca um PSP mas PSP é muito pesado mesmo. Não é o indicado. O ideal é até Gameboy Advance. Assista o review do Russ:

Numa classe um pouco superior, mais parecida com Ambernic RG35XX vertical, tem os Retroid Pocket Classic. Eu nunca tive, mas ouço falar muito bem também. Em particular a versão com 6 botões igual controle de luta do Mega Drive/Sega Saturn:

Também é uma boa recomendação e tem o review do Russ.

Ambernic RG35XX SP

Se eu tivesse que escolher só um, ficaria bem dividido com o TrimUI Brick, mas acho que acabaria sempre voltando pra este: Ambernic RG35XX SP

Como expliquei antes, RG400M significa tela de 4", então RG35XX significa tela de 3.5". É um pouco maior que os 3.2" do TrimUI Brick, um pouco menor que o RG477M. Na minha opinião acho que este é o “sweet-spot” entre portabilidade e visibilidade.

O “SP” significa que ele copiou o formato do lendário Gameboy Advance SP", a segunda revisão da Nintendo que introduziu o formato “clamshell”, que se dobra ao meio. A grande vantagem é que esse formato protege a tela quando fechada e não precisamos de uma bolsa pra quando queremos jogar na mochila, preocupados em riscar a tela.

Em termos de specs, todos os que falei até agora tem performance parecida. Os RG477M são mais poderosos porque rodam Android (que é bem mais pesado), os demais rodam Linux então é bem mais leve.

Novamente, depende muito de quem é você. Por exemplo, eu tenho mãos pequenas, e mesmo pra mim um Miyoo Mini e até mesmo o TrimUI Brick eu sinto desconfortável pra jogar por muito tempo. Tenho que ficar segurando o console só com os dedos. Já o RG35XX SP se apoia na palma das minhas mãos, então eu sinto muito mais confortável e ergonômico pra jogar.

Por causa disso também eu não recomendo a nova versão RG34XX SP:

Também não recomendo o Miyoo Flip v2:

O diferencial deles são os dois controles analógicos no final, que seria bom pra jogar coisas como Nintendo 64, os jogos mais novos de PS1, PSP, Dreamcast. Mas tem um porém: nenhum deles tem potência suficiente pra jogar acima de PS1. Sim, dá pra jogar mais ou menos bem Nintendo 64 e Dreamcast, mas não roda tudo.

Daí o que eu elogiei que dá pra apoiar na palma da mão se perde com os analógicos, porque pra usar os dedões nele, precisa segurar o handheld muito pra cima pra alcançar. Daí tem outro problema: os botões de ombro, que ficam atrás, os L1 e R1, ficam longe de apertar com os indicadores. Pra jogar FPS (jogos de tiro em primeira pessoa), é horrível. Então um Golden Eye 007 do Nintendo 64 fica ruim de jogar, mesmo com os analógicos.

Além disso note o nome: RG34XX, significa que a tela cai de 3.5" pra 3.4". Falei antes que eu acho 3.5" ideal e nessa nova versão é um downgrade. O erro é tentar achar que dá pra ter um único handheld que vai ser bom pra tudo. Não tem isso.

Outro canal que eu gosto muito é o Wulff Den e ele faz essa consideração nesse review:

Minha recomendação sempre é o RG35XX SP. Não precisa de botões analógicos e vai rodar tudo até PS1 sem problemas. Mais que isso, você quer um handheld MAIOR e mais potente.

Na categoria “clamshells” um que vale a pena olhar é o Retroid Pocket Flip 2, que é maior, mais potente e mais caro. Mas ouço falar bem também:

Novamente, assista o review do Russ

Ayn Odin 2

Vamos falar dos mais potentes. Pra mim, o melhor de todos, que roda basicamente tudo até Nintendo Switch, é o Odin 2 - e está pra sair o Odin 3, que vai ser melhor.

O preço não é muito maior que o RG477M, mas ele é infinitamente melhor. Na faixa de USD 300 (sem frete, sem impostos), é o melhor custo-benefício.

Veja as especificações, é um Qualcomm Snapdragon 8 Gen 2. É o mesmo chip que se tem em smartphones Android midrange pra high-end. Com GPU Adreno 740 e de 8GB até 16 GB LPDDR5X. Bateria de 8.000 mAh (maioria dos smartphones nessa categoria tem bateria de 5.000 mAh ou menos).

O principal: é uma tela IPS 6" de 1080p de resolução (Full-HD). Nesse tamanho, até eu que sou cegueta, consigo enxergar qualquer jogo sem problemas. Um Nintendo Switch original tem tela de 6.2", então é levemente menor. É basicamente a potência de um Switch 2, na realidade.

O review do Wulff Den diz tudo:

Na prática, veja na foto os controles: se quiser ter sticks analógicos, eles precisam estar no formato de Xbox ou Switch, na horizontal, esse é o formato mais ergonômico pra jogar por bastante tempo. Por isso falei que os Miyoo Flip ou RG34XX SP não vale a pena. No Odin 2 sim, dá pra jogar Halo, Golden Eye, Doom, etc sem problemas. E como é um Android também dá pra instalar Call of Duty da Play Store sem problemas.

Agora, minha reclamação pessoal: Android é BEM mais chato pra configurar emuladores do que Linux. De longe mesmo. Precisa de MUITO tempo, MUITA paciência e MUITA tentativa e erro até deixar do jeito perfeito. É tanta coisa que recomendo assistir o guia do Russ sobre isso:

Sério, assista o video, leia o blog post do site dele pra mais detalhes. Você não vai acertar de primeira.

Pelo menos, uma vez configurado, vai rodar tudo liso. PSP com 3x resolução, Dreamcast com 3x resolução, PS2 com 3x resolução, GameCube com 2x resolução, até Switch Full-HD Docker mode. É meu modelo preferido pra jogar PSP mesmo: Ridge Racer 2 fica perfeito.

Nessa categoria de Android horizontal, outra boa recomendação é o Retroid Pocket 5, na mesma faixa de preço e também ouço falar bem. Em particular todo mundo fala muito bem da qualidade da tela.

Novamente, assista o review do Russ.

Ayaneo Pocket DMG

Se tiver dinheiro pra jogar fora mesmo, também recomendo o Ayaneo Pocket DMG. Esse monstro começa na bagatela de USD 420 (sem impostos, sem frete, na config básica). Se escolher tudo, sobe até USD 690. Mais caro que um Playstation 5!!! Realmente não dá pra recomendar, é o pior custo-benefício de todos.

Ele é mais potente que o Odin 2 com um Snapdragon G3x Gen 2 e Adreno A32. É comparável a um bom Samsung Galaxy da vida.

A construção dele é super-premium, case, botões, tudo. A tela é um pouco pequena, de 3.92" (acima do que eu falei que considero ideal no 35XX SP), mas é OLED, super nítido, super brilhante, cores super saturadas, uma das melhores telas em qualquer handheld, comparável mesmo à tela de um Samsung Galaxy. Não tem como errar com essa tela. Todo jogo fica ainda mais bonito nela. Por isso custa caro!

Pra não dizer que é perfeito, os botões são um pouco “mushy” enquanto eu prefiro botões mais “clicky” com os Ambernic. Mas não significa que são ruins.

Por ser potente, também rodaria até Nintendo Switch sem problemas, mas aí a limitação é o tamanho da tela. Não acho que vale a pena rodar jogos feitos pra TVs grandes numa tela tão pequena assim. Ela é melhor mesmo pra retro-games, mas vai rodar PS2 e Gamecube de boas mesmo, com todos os filtros e upscaling que quiser pra deixar mais bonito que o original.

O review do Wulff Den diz tudo:

Sendo Snapdragon, esse handheld também é Android, então também é um saco de configurar. Mas no final roda tudo direitinho mesmo. Só seguir o guia do Russ.

Ele tem esse stick analógico no canto inferior esquerdo e tem um touchpad na direita que simula stick analógico direito. Não é confortável pra FPS, é usável pra algumas coisas como reposicionar câmera em jogos de plataforma 3D. Mas não espere usar o tempo todo. Tem o mesmo problema do Miyoo Flip que falei acima: fica MUITO pra baixo. Não é confortável num handheld vertical.

Se quiser jogos que requerem sticks analógicos, é melhor ficar num handheld horizontal, como o Odin 2, SteamDeck, Rog Ally, etc. O nome DMG é de Dot-Matrix Gameboy, que é o Gameboy Clássico. E o Pocket DMG de fato tem todos os fatores nostálgicos do DMG.

Eu, que tive o clássico, gosto muito desse formato. Mas eu acho que se você não tem nostalgia desse período, não vai fazer muita diferença. Esse formato limita jogos feitos pra telas wide-screen. Nesse caso o formato horizontal similar a Nintendo Switch é mil vezes mais ergonômico.

Como falei antes, é pra quem tem nostalgia e dinheiro pra jogar fora. Nada justifica comprar esse aparelho, por melhor que ele seja. É pra colecionador como eu. Odin 2 ou Retroid Pocket 5 tem custo-benefício melhores pra essa categoria.

Analog Pocket

Falando em caros, chegamos na categoria super-premium. E o mais super-premium de todos com certeza é o Analog Pocket.

Essa desgraça nunca está em estoque. Eu mesmo encomendei na época da campanha de lançamento na Indiegogo e levou acho que 1 ano pra chegar na minha casa. Custou os olhos da cara e mais alguns rims com os impostos do Brasil.

Ele é caro, mas o Pocket DMG é mais caro. Felizmente o preço hoje - se estiver em estoque - é “só” USD 220 (sem frete, sem impostos). É razoavelmente acessível. Mas ele é feito pra um público muito específico: quem gosta de FPGAs.

A Analog é famosa por não usar emuladores via software, como RetroArch. Todos os handhelds que comentei até agora usam emuladores: Citra, RPCS3, PCSX2, DuckStation, Sudachi, Yuzu, etc.

O Analog Pocket vem com o Altera Cyclone V FPGA. Ele foi feito pra rodar consoles antigos como se fosse o hardware original. Não é 100% perfeito (porque os cores de cada console são codificados via engenharia reversa dos chips, mas não é garantia que foram clonados 100%, depende de quem codificou os cores).

No caso do Pocket, ele tem slot pra encaixar cartuchos de verdade de Gameboy e Gameboy Advance. Dinamicamente ele copia a ROM pra memória RAM, carrega o core do Gameboy, e dali é como se estivesse rodando um Gameboy de verdade, no hardware original. Então coisas como frame lag, input lag, e qualquer tipo de latência são minimizados ou zerados. E se jogar lado a lado com um Gameboy de verdade, ele tende a ser idêntico, frame a frame.

Pra maioria das pessoas, na prática, isso não importa - ninguém vai ficar comparando quadro a quadro e a maioria dos emuladores via software hoje fazem um excelente trabalho de emular os consoles antigos de uma forma que um jogador médio não vai perceber a diferença. É realmente só pra quem entende os detalhes, como speed runners. Eu mesmo não noto a diferença.

Mas a grande vantagem desse console, pra mim, é a tela. O tamanho dela é só 3.5" e é IPS, não OLED. Mas é um dos melhores IPS do mercado. Brilhante, boas cores. Mais importante, é a mais densa do mercado com resolução absurda de 1600x1440 pixels (absurdos 615 ppi).

Isso é exatamente 10x a resolução do Gameboy original. Significa que ele consegue fazer upscaling de 10x pixel-perfect. Cada 1 pixel do Gameboy original vira 10 pixels no Analog Pocket. Com isso é possível também colocar filtros que simulam a tela dot-matrix verde antiga, no nível do sub-pixel, simulando todos os efeitos colaterais daquela tela obsoleta, trazendo uma sensação ainda mais perfeita de estar jogando um Gameboy de verdade.

Não é exagero. Olhem nessa foto, a simulação dos pixels do LCD antigo. Você enxerga exatamente o mesmo comportamento dos pixels com latência do LCD verde.

Acho que ninguém fez um review mais detalhado do que a Digital Foundry:

Essa tela, sozinha, é razão suficiente pra ter um Analog Pocket se você for um aficcionado por retro-games como eu. É item de colecionador que aprecia qualidade de verdade.

Além disso, eles abriram suporte a openFPGA e isso dá possibilidade de instalar dezenas de outras cores de FPGA feitas pela comunidade open source.

Existem várias ferramentas pra instalar e organizar esses cores, como o PocketSync

Tem FPGAs de arcades antigos, CPS1, NeoGeo, Lynx, PC Engine e muito mais. É como ter o hardware original desses consoles no seu bolso. Não tem experiência igual.

Sim, dá pra rodar tudo isso num emulador no seu PC. Mas vai por mim, essa tela é impressionante. Igualmente tão impressionante quanto o OLED do Pocket DMG. Eles ficam pau a pau em nível de qualidade, mas o Analog tem mais densidade de resolução ainda.

Menção Honrosa: Razer Kishi

Notem como metade dos handhelds que eu falei acima são todos Android. Basicamente chips de smartphone mesmo. Daí você já deve ter pensado, “ué, porque não jogar direto no meu smartphone então?”

E você está correto. Pra isso existem controles especiais pra smartphones, como o meu favorito, o Razer Kishi

Pra você que não pode sair de casa sem seu Genshin Impact, essa é a melhor opção mesmo:

Eu sei que existem outras alternativas, algumas genéricas do AliExpress, e eu não conheço elas. Procure o review específico no YouTube. Cada uma tem suas características. E por causa de tamanho, posição da porta USB-C e coisas assim, nem todo modelo encaixa, por isso é bom ver o site do fabricante pra ver se seu modelo vai encaixar nele. Não é garantido.

Mas ele basicamente funciona como um controle de Xbox conectado via Bluetooth ou USB-C no seu smartphone. Só isso.

O guia de Android do Russ vale pro seu smartphone também então dá pra instalar emuladores e jogar retro-games igual um Odin 2 ou Pocket DMG. A tela de smartphone normalmente é maior e você já carrega ele no seu bolso todos os dias, daí não precisa carregar um segundo dispositivo.

O controle em si não é pequeno, mas é leve. Tem num case que é fácil de jogar na mochila e não ter problema:

Então sim, não precisa gastar a mais com um novo handheld, use seu smartphone ou aquele mais velho que você encostou e não tinha uso pra ele. Pra retro-games vai funcionar muito bem.

Rog Ally X

No outro lado espectro, se quiser o mais poderoso e o mais versátil de todos, tamanho não for problema, dinheiro não for problema, vá pra um Handheld PC mesmo. Na minha opinião, o melhor ainda é o ASUS Rog Ally X

Esse é caro nível notebook, porque é basicamente isso que ele é: um notebook num formato mais compacto. Tem as mesmas tecnologias de um notebook.

A primeira versão (que ainda é boa e superior ao Steam Deck), num Mercado Livre, vai ser faixa de BRL 5.000. A segunda geração que é o “X”, com chip Z1 Extreme vai ser nada menos que uns BRL 15.000. Como falei é nível de notebook e iPhones.

Mas também, se conectar em qualquer Dock USB-C, dá pra conectar num monitor externo, teclado, mouse e ele vira um PC mesmo, rodando Windows 11 normalmente. Dá pra usar pra navegar a web, ver seus e-mails, até programar.

São 24GB de LPDDR5X-7500 (compartilhada com a iGPU Radeon) é bem rápida, tem 2TB de NVME 2280 (full-size), tela de 7" IPS (1" maior que o Switch Original, 1" menor que o Switch 2, Full-HD, 1920x1080 pixels, 120hz, 500 nits de brilho).

O SOC Z1 Extreme é Zen 4, com 8 cores, 16 threads, boost até 5.10 Ghz, com Radeon 780M (12 CUs), TDP de 15 a 30W (essa é a parte que ele é mais fraco que um notebook, lógico, não tem espaço pra dissipar mais calor).

Em comparação a outros chips, ele é mais rápido que um antigo Ryzen 9 5980HS, mais rápido que um Ryzen 5 7535HS. Ou seja é classe de um Ryzen 9 HS. Não chega a ser classe desktop como um Ryzen 9 7945HX ou 8945HX, mas pra um handhed, é muita potência.

E sim, tem outros similares no mercado hoje, como o Lenovo Legion Go que tem tela maior ainda de 8" 120hz, mesmo Z1 Extreme. Ou o Legion Go 2 já com Z2 Extreme, que é arquitetura Zen 5.

Tem o MSI Claw A8 também com Z2 Extreme, tela de 8" 120hz.

Qual o melhor? Não sei. Eu só experimentei o Rog Ally X. Recomendo assistir os reviews do ETA PRiME. Ele faz as melhores comparações de performance e benchmarks desses chips.

A ASUS também firmou parceria com a Microsoft pra lançar o novo ROG Xbox Ally, com Z2 Extreme e um OS de Xbox adaptado pra handheld, que tira a principal desvantagem desses handhelds todos: o fato que Windows 11 é um dos piores OS de todos os tempos pra handhelds. Dá pra usar, mas é bem gambiarra. Já com esse OS oficial, é como se tivesse um Xbox Series no bolso de verdade, com capacidade pra rodar jogos de Steam e outra lojas também.

Eu não tenho, mas fiquei com vontade de experimentar.

Todos esses são mais potentes que o SteamDeck, mas este ainda continua sendo o melhor custo-benefício no segmento e com o melhor ecossistema de mods, acessórios, e tudo mais. E a Valve tem dado bom suporte de atualizações.

Graças a tecnologias como FSR, hoje em dia dá pra fazer upscaling de resolução e frame generation via IA pra ter mais FPS. Então, jogando em medium settings ou low settings, não fica tão ruim. Com chips Z1 Extreme, Z2 Extreme e Ryzen AI Max+, já dá pra subir pra medium ou até high settings e ficar com bom FPS em Full-HD (1080p).

Todos eles tem saída HDMI, então dá pra ligar numa TV ou monitor. Todos eles aceitam controles externos Bluetooth, então dá pra ligar seu controle de Xbox ou 8BitDo da vida. E ele vira tanto um console quanto um handheld.

Mas são caros, faixa que vai de USD 600 a USD 900 dependendo da marca e modelo. São mais caros que um Playstation 5 e quase faixa de um bom notebook mesmo. Dependendo vale mais a pena comprar um notebook com Ryzen AI Max, que vai ter a mesma Radeon integrada e suportar bons jogos.

Portáteis Originais

Vamos a outra constatação importante: qual a melhor forma de jogar handhelds antigos com duas telas, como Nintendo DS e Nintendo 3DS?

Simples: nos handhelds originais.

A forma mais fácil de jogar jogos piratas neles é com os cartuchos R4, acho que não é difícil achar eles em Mercado Livre ou AliExpress. Eles aceitam microSD card e você joga suas ROMs nela, coloca no 3DS e já era.

Nintendo 3DS teve “end-of-life” recentemente e desde então todos os jogos estão facilmente disponíveis online. Leia o Guia de Hacks do 3DS pra saber como desbloquear o seu. Os jogos estão todos no hShop e quando desbloquear seu 3DS vai instalar o App pra abrir esse site e de lá pode baixar direto as ROMS pra memória interna do aparelho também. Existem várias opções.

Também é possível instalar emuladores no 3DS: vai rodar Gameboy, até Genesis e Master System. Não espere rodar um PS1 ou PSP nele, obviamente, é um hardware fraco.

Só tem uma coisa que me desagrada: as telas são velhas e antiquadas. Tem baixa resolução, baixo brilho, baixo contraste. Comparado com a tela do seu smartphone, nem chega aos pés. Mas pra jogar em dual screen, não tem jeito mais fácil.

Sim, vários fabricantes vieram tentando fazer handhelds com duas telas, como o Ayaneo Flip DS mas é extremamente chato de usar ele. Veja este review do Wulff Den:

São extremamente caros (Android ou Windows) e a experiência de software ainda é extremamente ruim. Não compensa pelo que se paga. Melhor ficar com os originais.

No caso de Gameboy Advance, já existem dezenas de bons handhelds com emuladores, então é melhor ficar com os RG35XX SP que eu já recomendei antes.

Mas, caso queira explorar a comunidade de mods, recomendo muito o site Boxy Pixels que fazem cases em alumínio e diversos acessórios pra dispositivos antigos, seja Gameboy, DS, até iPods. Veja este video do canal Macho Nacho que demonstra como fazer esse mesmo Gameboy Advance SP em alumínio:

Foi por causa desse canal que eu comprei o kit e montei o meu. É caro, é um hobby pra entusiastas mesmo. Isso não é pra amadores! Mas se tiver essa vontade, tá aí o site e o canal pra guiar.

Além disso, dá pra jogar ROMs piratas no Advance também. Similar aos cartuchos R4 pra 3DS tem os cartuchos EZ-Flash tanto pra Gameboy DMG/Color quanto Advance. Também são adaptadores de microSD card, onde você joga suas ROMS, pluga no hardware original e ele vai bootar um menu pra escolher as roms.

Eis um exemplo do EZ-Flash no meu Advance SP modificado. A tela está com white balance errado não sei porque, talvez eu tenha cometido algum erro ao montar, mas não parei pra consertar ainda. O importante era só mostrar o menu que aparece no boot pra escolher o jogo.

O cartucho funciona até no Analog Pocket, mas é redundante porque no Pocket posso jogar os ROMs direto nele.

Os Softwares

Agora deixa eu resumir o que você precisa saber de emuladores. O primeiro e mais importante de todos é o RetroArch.

Ele não é um emulador, ele é um front-end pra emuladores. É uma forma mais fácil de instalar os diversos emuladores individuais, cheats, save states, configurar controles que funcionam em todos, filtros, e muito mais.

Os emuladores mesmo ele chama de “Cores” que são “wrappers”/“adaptadores” pros emuladores de verdade. Cada sistema tem diversos emuladores feitos por diferentes pessoas ou grupos, que focam em coisas específicas (rodar maior quantidade de jogos, rodar menos jogos mas com precisão, conseguir rodar com menos recursos - bons pra handhelds fracos, etc).

Vamos ver uma lista básica (isso muda o tempo todo):

Nintendo

• NES: Mesen, Nestopia UE. Ouma
• SNES: bsnes, Snes9x. Ouma+1
• N64: Mupen64Plus-Next (+ParaLLEl-RDP/Angrylion), Project64. Libretro Docs+2Libretro+2
• GameCube/Wii: Dolphin. Dolphin Emulator
• Wii U: Cemu. Cemu
• Switch: Yuzu, Ryujinx
• GB/GBC: SameBoy, Gambatte. sameboy.github.io
• GBA: mGBA. BSNES
• NDS: melonDS, DeSmuME. GitHub
• 3DS: Lime3DS → now Azahar (successor fork). redream.io
• Virtual Boy: Mednafen VB (Beetle VB). Emulicious

Sega

• SG-1000/Master System/Game Gear: Emulicious, Genesis Plus GX.
• Mega Drive/Genesis: BlastEm, Genesis Plus GX. AirDroid
• Sega CD: Genesis Plus GX. AirDroid
• 32X: PicoDrive. GameTechWiki
• Saturn: Beetle/Mednafen Saturn, Kronos/Yaba Sanshiro (faster). GitHub
• Dreamcast/Naomi: Flycast, Redream. mamedev.org+1

Sony

• PlayStation (PS1): DuckStation (accuracy/perf), Beetle PSX HW/SW. Emulicious
• PlayStation 2: PCSX2. pcsx2.net
• PlayStation 3: RPCS3. RPCS3+1
• PSP: PPSSPP. RPCS3
• PS Vita: Vita3K. GitHub
• PS4: shadPS4 (rapid progress; still early). ShadPS4+2ShadPS4+2

Microsoft

• Xbox (OG): xemu, Cxbx-Reloaded. sameboy.github.io+1
• Xbox 360: Xenia. GameTechWiki

NEC / Hudson

• PC Engine/TurboGrafx-16(+CD): Mednafen (Beetle PCE Fast), Ootake (Windows). GameTechWiki+1
• PC-FX: Mednafen (Beetle PC-FX). Emulicious

SNK / Arcade & Handhelds

• Neo Geo AES/MVS (arcade): FBNeo, MAME. ppsspp.org+1
• Neo Geo CD: NeoCD (libretro), MAME. melonds.kuribo64.net+1
• Neo Geo Pocket/Color: Mednafen (Beetle NeoPop), RACE. GitHub

Bandai / Others (handheld)

• WonderSwan/Color: Mednafen (Beetle WSWAN). [sameboy.github.io](https://sameboy.github.io/?utm_source=chatgpt.com
• Atari Lynx: Mednafen (Beetle Handy). Emulicious

Atari (consoles)

• 2600: Stella. GameTechWiki
• 5200/8-bit: Altirra / Atari800. GameTechWiki
• 7800: A7800 (or MAME). GameTechWiki
• Jaguar: BigPEmu. mednafen.github.io

3DO / CD-i / Misc. classic

• 3DO: Opera (libretro). Libretro Docs
• Philips CD-i: MAME (best public option). Vita3K
• Vectrex: ParaJVE. vectrex-emu.blogspot.com
• Intellivision: jzIntv. intellivision.us
• ColecoVision: blueMSX (core) / MAME. Libretro Docs
• Magnavox Odyssey²/Videopac+: O2EM. o2em.sourceforge.net
• Fairchild Channel F, Bally Astrocade: MAME. Vita3K

Arcade (general)

• MAME (breadth/accuracy), FinalBurn Neo (speed/curation). Vita3K+1

Home computers (popular)

• Commodore 64/128/VIC-20/PET: VICE. vice-emu.sourceforge.io
• Amiga: WinUAE (Windows), FS-UAE (cross-platform). [winuae.net+1](https://www.winuae.net/?utm_source=chatgpt.com
• Atari ST/STE/TT/Falcon: Hatari, Steem SSE. hatari-emu.org+1
• ZX Spectrum: FUSE, Retro Virtual Machine. fuse-emulator.sourceforge.net+1
• MSX: openMSX, blueMSX (stale but usable; libretro core still common). openmsx.org+2msx.org+2
• PC-98: Neko Project II kai (NP2kai) (or DOSBox-X for DOS/V/PC-98 modes). Libretro Docs+1
• DOS / Win9x era: DOSBox Staging (games), DOSBox-X (games + Win3.x/9x).

Alguns emuladores são chatinhos, porque estão incompletos ou em desenvolvimento ou bugados ou sem suporte mais. Alguns exemplos:

• Xemu pra Xbox original funciona bem, mas é bem mal otimizado, portanto é bem pesado. Não vai rodar em nada que não seja pelo menos um handheld PC moderno como o Rog Ally ou um PC de verdade.
• Xenia Canary pra Xbox 360 ainda é bem bugado, só funciona em linha de comando (tem uma GUI de terceiros mais ou menos), tem que configurar arquivos pra tunar cada jogo. Meus jogos favoritos como Forza Motorsport 4 rodam com vários bugs visuais e crashes aleatórios que inviabiliza jogar (por isso comprei um Xbox 360 de verdade e desbloqueei).
• RPCS3 avançou bastante, mas não chega aos pés do PCSX2 ainda. Muitos jogos exigem configurações especiais - que não são intuitivos pra um amador, tem que ler o Wiki com muito cuidado, pra cada jogo. Jogos favoritos meus como Gran Turismo 6 ainda não rodam direito.
• shadPS4, esquece por enquanto, ele começou desenvolvimento recentemente, ainda é mais alpha que beta, quase nada roda nele sem muito trabalho. Não é pra amadores.
• Dolphin, até que é bem estável e quase plug and play, mas é mais pesado que um PCSX2. Não vai rodar em hardwares fracos.
• Mupen64 roda bem também, até em Android, mas nem todo jogo ainda roda nele e alguns rodam com pequenos glitches. No geral dá pra jogar, mas não espere perfeição.
• Emuladores de 8-bits, 16-bits, estão bem completos, estáveis, rodam liso qualquer um deles, pode confiar, incluindo arcades via Mame ou FBNEO. Mas no caso desses últimos, eles exisgem romsets (conjuntos de ROMS compatíveis com o emulador), não dá pra pegar qualquer ROM aleatória por aí e esperar que vai rodar. Fuce o Internet Archive pra achar alguns desses romsets.
• Home Computers como openMSX ou DOSBox, lembre que muitos jogos só funcionam com teclado ou mouse ou os dois e talvez não funcione muito bem mesmo mapeando pra controle. Tem que ler o Wiki de cada jogo pra saber.
• Por causa dos processos da Nintendo, emuladores de Switch aparecem e somem, alguém faz um novo fork e reaparece. Yuzu já foi fechado mas forks apareceram. Surgiu Suyu, mas fechou. Ryujinx continua funcionando e é o meu favorito. Android acho que tem Sudachi e outros. Tem que dar uma pesquisada.

RetroArch tem suporte pra quase todos esses emuladores. Portanto só instalando ele, já vai te dar acesso à maioria. Alguns é melhor instalar separado como apps individuais, em particular isso é verdade em Android, por isso falo tanto do guia do Russ e como Android é mais chato.

Em Linux, distros como OnionOS, GammaOS, Surwish, Knulli, MinUI, já vem com RetroArch instado e pré-configurado, por isso são mais fáceis de instalar e usar.

Dá pra usar só o RetroArch, seja em handheld, seja em Android, seja no Windows. Mas a interface dele é bem feia, velha, chata de navegar. Talvez você não se importe, mas depois que tem a experiência de console, como Playstation, Xbox, é chato usar uma interface velha. Pra consertar isso existem diversos front-ends pra colocar por cima do RetroArch, o mais famoso e popular de todos acho que é o EmulationStation

Ele é bonito, dá pra escolher vários temas e fica assim:

Novamente, o Russ do canal Retro Game Corps tem guias pra isso:

• Emulation Station em Android
• Emulation Station no SteamDeck
• Emulation Station no Windows

Tem mais videos, só pesquisar por “emulation station” direto no canal dele e também no blog dele. Tem dezenas de guias por aí, por isso não vou perder tempo detalhando ele. Pára de ter preguiça e pesquisa. O que não falta é material.

No mundo de handhelds Linux, também existe Emulation Station em distros como Knulli, que é um fork do antigo Batocera. E adivinhe: tem guia do Russ:

Já entendeu a única coisa que você precisa tirar deste artigo né: se tiver alguma dúvida sobre esse assunto, pergunte ao Russ, não a mim!

No mundo de SteamDeck e outros handhelds PC, existe outra distro Linux, o Bazzite que é um fork modificado do SteamOS pra rodar fora do SteamDeck.

Assim seu Rog Ally vai funcionar igual um SteamDeck mais potente! Rodando jogos de Steam em Linux via Proton. Eu pessoalmente não fui por essa opção porque já me acostumei com a chatice do Windows 11 e eu gosto de rodar WeMod pra rodar jogos com cheats. Além disso eu instalei outros emuladores que só funcionam em Windows, com os de Sega Model 2 e Model 3. Sim, tem como rodar em Linux com Wine e tudo mais, mas já tá funcionando, deixa assim. Faz no seu.

Pra Emulation Station e outros front-end como Daijisho no Android vão pedir pra você ter uma conta no site ScreenScrapper. Com essa conta dá pra ler as ROMs no seu microSD card e ir no site buscar coisas como imagem da caixa, video de demonstração e tudo mais pra ficar tudo mais bonito.

Última coisa: se eu tenho tantos handhelds, como faço pra compartilhar os saves entre todos eles pra continuar jogando de outro handheld?

Tem dois jeitos: o mais fácil é só tirar o microSD de um e colocar no outro e vai ter os mesmos saves. A outra forma - bem mais complicada (que é o que eu faço) - é subir um container de SyncThing, que é um serviço que syncroniza diretórios entre diferentes computadores (pense um mini-Dropbox). Pra variar, o Russ tem um tutorial:

Conclusão

Entendeu a mensagem do post? Não pergunte “Akita, qual retro-handheld é melhor pra eu comprar?” O coitado do Akita não é tech-reviewer pago, patrocinado, nem monetizado, portanto todos os handhelds que eu tenho, comprei só pra mim. Por isso não tenho nenhum Retroid. Não adianta perguntar se Ambernic ou Ayaneo são melhores que Retroid. Akita não vai saber.

Em vez disso perguntem a tech reviewers que são pagos a patrocinados pra falar disso. Eis minhas recomendações:

• Retro Game Corps
• Wulff Den
• Tech Dweeb
• Taki Udon
• ETA PRIME

Pra quem se interessa por mods:

• Macho Nacho Productions
• The Retro Future

E pra quem se interessa por consertos:

• TronicsFix

Todos eles vão dar respostas melhores sobre todas as suas perguntas sobre todos os modelos de handhelds, consoles, consertos, modificações, softwares, OS, customizações, ROMs e muito mais.

Eu fiz esta página só pra poder dar copy e paste do link pra todo mundo que repetir essas mesmas perguntas daqui pra frente. Acho que cobri tudo que eu sei do assunto!

Eu fiz questão de levantar um ponto que vale a pena complementar agora. Toda vez que você acredita num CEO de empresa que vende I.A., dizendo que “I.A. vai substituir pessoas” ou “AGI está batendo na nossa porta” ou “AGI vai ser catastrófico”, você está acreditando num traficante dizendo que cocaína é boa pra sua saúde.

Vamos a novas informações. Sundar Pichai é CEO do Google e um dos que disseram que “30% do código do Google” já é feito com I.A. (sem explicar, claro, “quais 30%” e nem mostrar nada).

Veja o mesmo Sundar Pichai hoje, 18/06/2025 no “Business Insider”

Interessante como o discurso ficou mais “pé-no-chão” agora. Mas ele não foi o primeiro. Já em fevereiro de 2025 o CEO da Microsoft, Satya Nadella disse o seguinte em artigos como este:

E por que esta mudança de discurso, sendo que no fim de 2024 tava todo mundo animado falando só “AGI”, “AGI”?

Existe uma cláusula na negociação de investimento da Microsoft com a OpenAI (eles investiram USD 14 bilhões) de que a OpenAI pararia de compartilhar tecnologia com a Microsoft, uma vez que “AGI” fosse atingida. Definida como “sistema altamente autônomo que ultrapassa humanos em trabalhos de mais valor econômico”. Essa é a definição.

Problema é que isso tira a Microsoft como investidor também. Além disso, recentemente a própria Microsoft começou a se declarar como um concorrente da OpenAI, em vez de parceira, se posicionando junto com um Google ou Claude. Leia os detalhes nesta análise:

Entenda: toda discussão de “é AGI, não é AGI” tem mais a ver com negociações por baixo dos panos entre as diversas Big Tech envolvidas e seus investidores. Não se relaciona com tecnologia de verdade. Você é só mais macaco de auditório de um show que nem pode assistir. Então está torcendo cegamente, pra variar.

Geoffrey Hinton e o problema dos especialistas

Saiu mais uma entrevista do tal Geoffrey Hinton, mais fatalismo, mais “já era” e mais gente gritando pelos cantos achando que Armageddon vai chegar amanhã.

A mídia considera Geoffrey Hinton o “Godfather das I.A.”

Por causa disso muitos acreditam em tudo que ele fala - “Lógico que o cara que inventou I.A. sabe o que vai acontecer”. Virou um culto.

Eu mesmo falei no Flow que ele inventou Backpropagation - o backbone de treinamento de I.A. -, mas é uma simplificação. O próprio Hinton já esclareceu diversas vezes que ele não inventou. O grosso do trabalho foi publicado por Paul Werbos e Shun-Ichi Amari. Mas de fato, foi o Hinton que popularizou esse trabalho.

Hinton, como professor, teve a sorte de supervisionar alunos que viriam a se tornar brilhantes. Na AlexNet - eu contei no Flow - como foi Ilya Sutskever quem deu a idéia de usar GPUs pra treinar deep neural networks. Ilya, que depois viria a co-fundar a OpenAI - junto com Andrej Karpathy, outro aluno brilhante de HInton e que hoje em dia eu detesto porque ele que cunhou o tal de “Vibe Coding”. Karpathy vem seguindo os passos do seu mentor Hinton e espalhando bullshit.

Ainda na revolução de computer vision, além de usar GPUs, o grande passo de arquitetura foram os Convolutional Neural Networks (CNNs), de Yann LeCun - outro aluno de Hinton.

O problema: a mídia dá mais crédito pro supervisor do que pro aluno. E coloca tudo no mesmo saco e fica como se Hinton - sozinho - inventou BackPropagation, CNNs e o AlexNet inteiro. O próprio Prêmio Alan Turing que ele levou, de novo o mérito foi da equipe, mas o nome “Hinton” é mais forte, então foi como se “ele” fosse o maior responsável. Óbvio, desse jeito, qualquer um parece um semi-deus.

Não estou dizendo que ele é burro nem nada disso. Mas não é tudo isso, não é infalível e certamente é um ser humano normal que erra. Não há correlação dos seus trabalhos anteriores com especulações de futuro.

Em outro espectro, existe um prêmio Nobel, Roger Penrose que postula desde os anos 80 ou 90 que “consciência NÃO é computável” por exemplo, em seu livro “The Emperor’s New Mind”. Um Nobel do nível que provou hipóteses de Einstein e trabalhou com Hawkings.

Além disso o próprio Yann LeCun, é do campo que não acredita que as I.A.s atuais vão chegar perto de AGI também. Como eu SEMPRE repito: precisa acontecer alguma nova descoberta - que ainda não sabemos - pra isso acontecer. LeCun tem suas teorias e está na Meta, trabalhando num projeto chamado V-JEPA pra ver se ele faz essa descoberta.

Em vez de ouvir Hinton, ouça um pouco de LeCun:

Pois bem, se “autoridade” é seu único parâmetro, deveria então acreditar cegamente em Penrose e LeCun também. E agora, como fica?

Este jogo é mais complicado do que sua mente ingênua de seguidor-cego consegue enxergar. Não seja só um macaco de auditório e entenda como as peças de encaixam.

“Você não consegue provar que AGI não vai existir”

É verdade, ninguém consegue. Ninguém consegue provar que Deus não existe. Ninguém consegue provar que Unicórnios não existem. Isso não significa absolutamente nada, é um erro de lógica.

Pessoas de fora de tecnologia e que nunca estudaram ciência da computação só conseguem ver o que os jornais publicam ou o que influencer fala de bobagem em podcast.

Vamos esclarecer: sim, todos nós - programadores formados em ciência da computação - sabemo que, com a arquitetura atual de LLMs, não há como chegar em AGI. Isso é uma certeza.

O problema é que vocês acham que nem nós sabemos tudo sobre I.A., que existe uma camada misteriosa dentro do modelo que funciona sem que nós saibamos como funciona.

Ou pior, vocês acham que somente alguns poucos nomes considerados importantes como Geoffrey Hinton ou Ilya Sutskever, é que conseguem entender. Entenda uma verdade importante: sim, pra chegar numa Teoria Geral da Relatividade, precisou de gênios gigantes como Albert Einstein, David Hilbert, Kurt Godel, etc. Um deles chegaria nisso, nem todo físico conseguiria.

Mas, uma vez descrita e entendida a Teoria, ela é facilmente ensinada pra alunos de 1o ano de faculdade. Não é nenhum segredo místico que precisa de décadas de treinamento pra entender.

Mesma coisa, perceptrons, redes neurais, backpropagation, gradient descent, RNNs, CNNs, Transformers, etc. Cada uma dessas etapas contou com alguns considerados gênios, como Geoffrey Hinton (que muitos vão dizer que só levou crédito, quem fez o trabalho mesmo foram os Sutkever ou LeCun). Mas uma vez entendido, isso tudo é matéria de graduação de ciência da computação. Você não precisa nem ser um PhD pra entender a maior parte disso.

Os modelos treinados funcionam porque sabemos como ajustar pra funcionar. Parte importante da fase de treinamento é alimentar as redes neurais com milhões de perguntas e respostas PRÉ-PRONTAS. Essa é a fase de INSTRUÇÃO e TODA LLM passa por isso. Ela responde exatamente como cada empresa por trás mandou ela responder, nada a mais que isso.

Ah, mas é tanto parâmetro que não tem com você saber tudo dela. Sim, temos, qualquer bom programador consegue carregar Tensorflow, PyTorch, carregar o modelo e explorar todas as dimensões. Conseguimos partir da resposta e olhar os passos pra trás e ver porque ela se formou daquele jeito. Podemos re-ajustar, podemos mexer quanto quisermos. Eu mostrei parte disso nos posts anteriores.

Todas as etapas do treinamento, da inferência, das otimizações, das metodologias de alinhamento, das estratégias de deployment, tudo está documentado e todos das ciências sabemos exatamente como tudo funciona.

Por isso é assustador que alguém como um Hinton ou Sutskever fiquem fazendo alarmismo sem demonstrar nada. Mostra como eles estão por fora do que está acontecendo. Yann LeCun está correto: está com a mão na massa e ele sabe que a arquitetura atual já bateu no teto e não há muito mais pra seguir daqui. Por isso ele iniciou outros projetos pra tentar conseguir descobrir o que seria uma NOVA arquitetura que leve à próxima etapa. Esse é o projeto V-JEPA 2 da Meta.

Só porque VOCÊ não sabe como as coisas funcionam, não pensem que há margem pra coisas de ficção científica. É a mesma coisa que assistir um filme como “O Chamado” onde espíritos malignos vivem numa fita de VHS e saem da TV, associar que espírito-onda de TV pode ter relação e me dizer “Você não consegue provar que não é possível”. É um nível de criancice e falta de conhecimento que não tem como começar a explicar.

Sempre, o ÔNUS DA PROVA é de quem VENDE a afirmação. Todo CEO de empresa de IA e todo acadêmico renomado - sem publicar nada - está afirmando isso. Não sou quem tenho que provar: são eles. Ninguém deve tentar provar uma negativa, não faz sentido.

De bônus, voltando pra Yann LeCun. Eu não acompanhava ele, fui ver só hoje o que ele fala. Achei interessante como ele argumenta exatamente as mesmas coisas que eu falo faz mais de 1 ano já. Não quero nem de longe dizer que sou nem uma fração da inteligência dele. Só que partindo dos mesmos princípios, dá pra inevitavelmente chegar nas mesmas conclusões. É inferência pura a partir de primeiros-princípios. Não é uma especulação. Se escrever “2 + 2” tanto eu quanto ele vamos chegar em “4”. Todo mundo está dizendo “mas se tiver poder de computação suficiente, um dia vai chegar em 10”. Não vai. Assista esta outra entrevista dele, é muito esclarecedor:

O que LeCun e outros - como DeepMind - já disseram, é que LLMs não tem capacidade pra chegar em AGI. Isso é sabido e a DeepMind já provou isso matematicamente. Este outro video tem mais detalhes. Mas em resumo, uma LLM é boa como “recuperador de informações”. Além do que eu chamo de “completador de texto glorificado”, quer dizer que ele só é capaz de completar com informação que ele já viu em treinamento (e combinações aleatórias que às vezes faz parecer que é informação nova, mas não é). A única forma dele conseguir resolver QUALQUER problema é ter um MODELO CAUSAL de TODOS OS PROBLEMAS. Ou seja, ele já saber de ante-mão a resposta pra toda pergunta. Obviamente não temos isso, portanto, é impossível que uma LLM - sendo uma máquina de recuperar informações - nos dê soluções que não existem, como “qual é a nova descoberta que vai permitir AGI?”. É um problema não-decidível e não-computável. Matematicamente provado como inviável.

AGI, na arquitetura atual, não vai acontecer. Precisa acontecer alguma nova descoberta. Isso pode ser daqui 2 anos, pode ser daqui 20 anos. Mas não há um caminho possível a partir do que sabemos hoje.

Finalmente resolvi compilar uma lista com os canais que eu mais assisto e uma lista das principais playlists e exemplos de videos de cada canal que recomendo assistir.

Provavelmente vou ficar voltando nesta página pra atualizar de tempos em tempos. Se alguém se lembrar de algum que eu esqueci, mandem nos comentários. Tem canais como GameSack ou Sega Lord X ou Retro Game Corp ou Wullfden ou Macho Nacho Productions e vários outros assim que não listei, porque são mais de “reviews” e não cruzam tanto com “dev”. Tentei focar em coisas que eu acho que um “dev” deveria saber.

Lista (2025-05-19)

• Usagi Electric
  • Playlists:
    • Bendix G15 Vacuum Tube
    • Data General Nova
    • DEC/PDP-11
    • 1-Bit Computer
• Tech Tangents:
  • Playlists:
    • Data Generals
  • Videos:
    • Tandy 1000 RL HD
    • CP/M on Model 100
    • KayPro IV
    • HP Series 200 - CAD Monster
    • 8088 PC Networking
    • FreeDOS on IBM 5150
• The 8-Bit Guy
  • Playlists:
    • Commander X16
    • Game Development - Making of Planet X2
    • Texas Tech History
    • Commodore History
• Adrien’s Digital Basement
  • Playlists:
    • TRS-80 Model II Repair Series
    • Amiga 4000 Repair Series
    • ZX Spectrum
    • IBM 16-bit machines
    • Apple Computers - 8-bit
    • Macintosh Machines - 68000
    • Commodore - 8 bit
    • Commodore 64 Repairs
    • Tandy 1000 Series
• clabretro
  • Playlists:
    • Home Lab
    • Sun Microsystem Stuff
  • Videos:
    • Ressurrecting an IBM PS/2 Model 50Z
    • Windows NT 4.0 on a Compaq Proliant Gen 1
    • Token Ring Networking
    • Early 2000s Linksys Wi-Fi Gear
    • Compaq Proliant Gen 1
• LowSpecGamer
  • Playlists:
    • All Lore - Chronological
    • Chip WarsNintendo Lore
    • The Yokoi Saga
  • Videos:
    • How Amateurs created the world’s most popular processor - History of ARM Part 1
    • ARM’s Secret Weapon - History of ARM Part 2
    • How IBM Invented the PC, then everyone stole it
    • The Great Calculator Wars of the 70s
• Ben Eater
  • Playlists:
    • Build a 65c02-based computer from scratch
    • Building an 8-bit breadboard computer
    • Networking Tutorial
    • Error detection
• javidx9
  • Playlists:
    • NES Emulator from Scratch
    • Code-it-Yourself - TETRIS from scratch
• Gaming Historian
  • Playlists:
    • Video Game Hardware
    • The Story of Super Mario - Documentary Series
    • History of Wolfenstein
    • History of Sonic the Hedgehog
    • History of Super Smash Bros
    • Games
    • Gaming Historian
• Modern Vintage Gamer
  • Playlists:
    • Mistakes Were Made - Game Console Security
    • The Sony Playstation
    • The Original XBox
    • Doom Switch Port
    • Retro Reviews
  • Videos:
    • N64: Decomp vs Recomp vs Ports explained
    • XenonRecomp
    • Game Genie Explained
    • Super NES Graphics
    • N64 Emulation is a Mess
    • The First Amiga Virus
    • 35 Years of Game Boy
    • Video game piracy in the 80s
    • Doom SNES Sourcecode
    • How Graphics worked on the Game Boy
    • How UltraHLE changed N64 emulation forever
    • How Diablo was completely Reverse Engineered without source code
    • Duke3D on the Amiga 600
• Strafefox
  • Videos:
    • Video Game Development Through the 80s
    • The 3D Revolution in 90s game development
    • The Making of Sonic the Hedgehog
    • The Making of Mortal Kombat
    • The Making of Castlevania Symphony of the Night
    • The Making of Donkey Kong Country & Killer Instinct
    • The Making of Aladdin
    • The Making of Streets of Rage
    • The Making of Street Fighter II
    • The Making of Super Mario World
    • The Making of Star Fox
    • How Video Games were Made - Part 3
    • How Video Games were Made - Part 2
    • MSX Konami Games
• GTV Japan
  • Playlists:
    • The GTV Binge Watch
    • GTV’s Greatest Hits
  • Videos:
    • The Story of Chrono Trigger
    • The Final 16-bit Fantasy
    • Sonic Mania Day
    • The History of Sonic - 30th Anniversary
    • The Super Story of Mario World
• Displaced Gamers
  • Playlists:
    • Game Genie: Uncorked
    • Talkin’ Code
    • Behind the Code
    • Gaming Tech Talk
• Retro Game Mechanics Explained
  • Playlists:
    • Super Mario 2
    • Super Mario Bros.
    • Super Mario World
    • Super Mario Bros 3
    • Super Mario Land 2
• The Cherno
  • Playlists:
    • Ray Tracing Series
    • OpenGL
    • Code Review
• Kosmic
  • Playlists:
    • World Record SpeedRuns
    • Super Mario Bros
• Kaze Emanuar
  • Playlists:
    • SM64: Last Impact - Developer Commentary
  • Videos:
    • Mario 64 breaks after 7 days
    • Perfecting Random Number Generation on N64
    • Planetary Gravity is Cheap
    • The Genius of N64 Cache Instruction
    • The N64 has more RAM than you think
    • Why Devs need to know about Render Matrices
    • Better engine, Better graphics
    • The Folded Polynomial
    • Fastest Sine on N64
    • Fixing the Entire SM64 source code
• James Lambert
  • Videos:
    • Can Portal64 be saved?
    • Portal 64: First Slice, is out of beta
    • How I optimized Portal to run on the N64
    • How I implemented MegaTextures on real N64 hardware
    • I rewrote Portal from scratch and solved the Portal Paradox
    • How are toon shading and dynamic shadows possible on the N64?
    • How can Nintendo 64 run Portal?
• Veritasium
  • Playlists:
    • Computing
  • Videos:
    • I build a QR code with my bare hands to see how it workds
    • Exposing the flaw in out phone system
    • The Trillion Dollar equation
    • The Most Important Algorithm of All Time
    • Math’s Fundamental Flaw
    • The Bayesian Trap
    • How Does a Transistor Work
    • How to Make a Quantum Bit
• 3Blue1Brown
  • Playlists:
    • Convolutions
    • Probabilities of Probabilities
    • Differential equations
    • Essence of Calculus
    • Essence of Linear Algebra
    • Neural Networks
  • Videos:
    • But what is a quantum computing - Grover’s Algorithm
    • Where my explanation of Grover’s algorithm failed
    • Large Language Models explained briefly

Tem sido muito útil pra mim especialmente pra resumir paper, conciliar pesquisas em vários sites, resumir tópicos e coisas do tipo.

“MAS ..”

E é um enorme MAS, ele tem sido BEM inútil em programação de verdade. Não vou repetir todos os problemas que já encontrei: eu detalhei bastante nos posts anteriores. Mas minha conclusão é simples: ele pode ajudar em código, em tarefas pequenas, focadas, isoladas, com bastante prompt pra ajudar e você - programador - precisa estar atento em o que escolher usar e o que vai rejeitar (e vai ser a maior parte).

Prompts melhores tem limites. RAGs tem limites. Loras tem limites. Janela de contexto maior tem limite. Usar agentes que devolver stacktrace e pedir pra fazer deep thinking, tem limites. Eu já consegui esbarrar em TODOS os limites e não achei nenhum “workaround” que consiga fazer ele funcionar 100% bem em 100% do tempo - que é a promessa que a propaganda faz.

“Mas a Microsoft, Google, Meta, NVIDIA já afirmaram que 30% do código deles já é feito com I.A. e ano que vem vai substituir programadores”

Essa é a grande meia-verdade, meia-mentira (interprete como quiser).

“Que 30%??”

Você, que não é programador, sabia que documentação de projetos (que é extenso), arquivos de tradução de línguas (que é extenso, sabe quantas línguas uma Microsoft ou Google suportam globalmente?), páginas HTML que duplicam essa documentação extensa, tudo isso é “considerado” parte do código e fica no mesmo repositório “de código” como GitHub?

Você, que não é programador, sabia que o VOLUME em caracteres/bytes desse material, muitas vezes quase iguala ou até pode superar o volume de bytes do código em si?

Esse é só um pequeno exemplo que me vem à cabeça. Páginas de lançamento de produtos novos, os “hot-sites” que são sites DESCARTÁVEIS e feitos pra jogar fora. Isso também é volume de código. Tem MUITO “código” que não é “O código”. Todo programador que trabalha numa grande empresa sabe disso.

O seu projetinho caseiro não tem documentação, não tem testes automatizados, não tem scripts de build, não tem automação de deploy ou empacotamento, não tem arquivos de línguas separado, não tem hot-site, não tem site de produto em múltiplas línguas. É só um “hello.py” e esse é TODO o seu código. Entendo porque você extrapola que projeto grande é a mesma coisa.

PARTE dos “30%” que tanto se fala é isso. Claro que tem algum código de verdade, mas não é nem perto do que você pensa.

Conflito de Interesses

Eu fico pasmo. Se um “vendedor de entorpecentes” te dá uma amostra grátis e você pergunta “mas é seguro”. O que você acha que ele vai responder?

O dono da Meta tem produtos de I.A. O dono do Google, o dono da Microsoft, ALUGAM GPUs pra I.A.. O dono da NVIDIA VENDE GPUs pros datacenters de I.A. O dono da OpenAI, Anthropic, todos ALUGAM essa infra e te REVENDEM, CRÉDITOS DE TOKENS.

Qual você acha que é o incentivo deles? VENDER USO TOKENS.

Vocês viram meu relato nos posts anteriores. Em menos de 1 semana de testes eu gastei quase USD 150 de créditos. Seriam mais de 850 BRL, em uma semana, e depois de fazer uma CENTENA de tentativas, eu obtive refatoramentos meraramente “razoáveis” METADE das vezes, e eu obtive bons testes unitários que passam, MENOS DA METADE das vezes (na verdade, quase NENHUMA vez). Mas eu gastei token, MUITOS TOKENS.

Funcionalidades que a propaganda te fala que melhoram como DEEP THINKING/REASONING, só “às vezes” dão respostas de código melhor. Eles de fato são melhores pra compilar papers ou pesquisas de texto. Mas pra código, na MAIORIA das tentativas, eu não vi tanta diferença. Só que demorou MUITO mais e gastou MUITO mais tokens. Sabe o que Deep Thinking faz? Ele adiciona mais passos até a resposta e enche o contexto com tokens. Esses tokens extras: VOCÊ PAGA A MAIS.

Funcionalidades que a propaganda também te fala que melhorar como soluções baseadas em RAG, no fundo é só mais “injeção de prompt” - que sempre gasta contexto e GASTA MAIS TOKENS. Funciona, claro, mas o incentivo é gastar mais tokens.

Funcionalidades que a propaganda agora tenta te empurrar como MCP, agentes e automação de LLMs, somado com RAGs e tudo mais. Os Devin, n8n, e tudo mais são uma forma mais automatizada de GASTAR MAIS TOKENS.

Todo o incentivo, de todo mundo, é gastar mais tokens, não menos. E nos meus testes, em muitos modelos (não vou dizer todos), eu obtive respostas melhores de código DESLIGANDO DEEP THINKING. Dá pra configurar isso em ferramentas como Aider ou direto na API da OpenAI. Diminuir thinking_tokens ou fazer reasoning_effort ser “Low” ou melhor, “NONE”.

LOOT BOXES

Também expliquei no artigo sobre como fazer seu próprio Modelfile de Ollama que, essencialmente, o processo de geração de textos (engula, LLMs são geradores de próxima palavra), tem componentes aleatórios. Temperatura, Top_P, Top_K. Mais: o treinamento tem componentes não-lineares (ex. ReLU). Não é determinístico, é um SORTEIO numa distribuição de probabilidades.

Significa que, fundamentalmente, não tem como uma LLM estar 100%, 100% do tempo. É matematicamente impossível. Ele sempre pode estar “quase certo” ou “parecendo que está certo”. Mas se você diligentemente rechecar tudo, o tempo todo, vai começar a encontrar pequenos equívocos. No caso de código, é bem mais aparente. Ele está BEM errado, MUITAS vezes.

E o processo todo se assemelha muito a jogos online “gratuitos” com LOOT BOXES ou sistemas de GATCHA, sabe? Tipo Genshin Impact da vida.

O quê??? Você é um boomer e não sabe o que são Loot Boxes? …

EU SOU BOOMER E EU SEI, não tem desculpa. Vai se atualizar (e é a principal razão de porque eu escolho não jogar esse tipo de jogo online).

A economia desses games funciona assim: você não tem a opção de comprar ítens específicos que quer. Em vez disso, você paga, digamos 20 créditos pela chance de participar de um sorteio (que acontece em datas e horas pré-programadas, não o tempo todo). Nesse sorteio você tem a (ALTA) probabilidade de só ganhar um ítem de 10 créditos OU, a incrível (BAIXÍSSIMA) probabilidade de ganhar um ítem exclusivo de 1000 créditos!!!!

Parece um negócio da China né??? (LITERALMENTE É!!!)

Você sempre ganha o item mais barato no sorteio. E de vez em quando ele te dá um item MÉDIO pra você não desistir de continuar e achar que tem alguma chance real. Só se você gastar MUITO (e nesse ponto você já gastou mais de 1000 créditos mesmo), só aí talvez ele te dê um item grande, pra te injetar de mais dopamina e aumentar seu vício.

É exatamente isso que acontece com LLMs. As respostas deles tem chances parecidas com de Loot Box. Às vezes ele te surpreende com uma excelente respostas, mas na maior parte do tempo, você fica pedindo “cara, você tem certeza dessas resposta?”, ou “cara, não tá errada essa segunda linha?”, ou “cara, reveja o que eu perguntei e tenta de novo”. e assim vai o seu dia inteiro.

Você não fica olhando, mas por baixo dos panos, cada vez que tem que corrigir, ele continua gastando os mesmos créditos. No final do dia, lá se foram USD 50. Parece pouco, mas faça isso todo dia e veja quanto acumula.

Só que seu VIÉS DE CONFIRMAÇÃO faz você se lembrar bem de quando ele acertou, mas vai “esquecendo” todas as outras vezes que ele errou. E sua percepção é que “Sim, ele funciona.”

Pior, sua baixa auto-estima e necessidade de se fazer parte de um grupo, de se CONFORMAR. Corroborado com o que lê diariamente nas notícias, como:

• 30% de todo código da Microsoft já é feita por I.A.
• CEO da Anthropic diz que ano que vem programadores serão substituídos por virtual workers
• CEO da NVIDIA diz que não recomendaria seu filho a estudar mais programação

E tudo isso AUMENTA O VIÉS: você acha que eles estão certos, as vezes que você mesmo experimentou a LLM errando “deve ter sido uma pequena exceção, eu que sou burro mesmo” e ACREDITA na MENTIRA.

Quem lembra das minhas palestras de 15 anos atrás onde eu mostrava este video?

Isso é um fenômeno bem conhecido, hoje em dia mais amplificado pelas redes sociais e a burrice de jornalista, que só repete o que ouve como papagaio e não faz mais perguntas críticas, do tipo: EXISTE CONFLITO DE INTERESSES??

“OpenAI usa seus chats pra treinar?¨

Aqui vou ter que consertar uma mentira que eu venho contando pra vocês. Eu sempre repeti que não. Sua conversa não é usada pra treinamento, porque iria poluir o material de treinamento com lixo que no final não iria melhorar as respostas.

É meia-verdade. De fato, eu duvido muito e boto minha mão no fogo: nenhum provedor quer se arriscar a alguém encontrar um texto com copyright e levar processo. Isso já acontece, o New York Time processou porque o ChatGPT conseguiu reproduzir um texto publicado por eles. E isso meio que “prova” que fazia parte do material de treinamento.

Tem gente que coloca coisas privadas como condições de saúde, situação financeira, e até mesmo dados críticos como senhas, endereço, coisas que não deveriam mas acabam publicando porque não tem noção sobre cyber-segurança. Todo mundo cai num golpe todo dia por causa disso. A OpenAI ou Meta ou Alibaba não fazem questão de aparecer isso uma hora no chat e viralizar notícia internacional falando como eles foram irresponsáveis.

MAS

E é um GRANDE “MAS”, eles usam sim seu chat. De todo mundo. Sem copiar nenhum dado seu. Eles só precisam dos METADADOS, os dados que descrevem seu chat.

De cabeça aqui, sendo ingênuo e amador em treinamento, eu vejo pelo menos 2 informações importantes que você dá pra eles: o comprimento do seu chat e o sentimento das suas respostas no chat.

Determinar sentimento a partir de texto é um problema bem resolvido, tem algoritmos com ou sem redes neurais que conseguem determinar se o texto parece feliz, triste, bravo, angustiado ou coisas assim. Eles não precisam do conteúdo do seu texto, só precisam do SENTIMENTO que você teve na hora.

Somado ao COMPRIMENTO do seu Chat e como eu falei no post anterior, que o incentivo é fazer você gastar MAIS TOKENS (chat MAIS longos). NO PRÓXIMO POST vou ensinar vocês como eles fazer alinhamento, o “fine-tuning” do modelo. Uma OpenAI usa milhares de linhas de pares de prompts/completion pra “forçar” o modelo a responder de uma determinada forma. Pensa um Excel cheio de perguntas e respostas pré-prontas, que segundo seus metadados, sabemos que são as respostas mais POPULARES.

O objetivo não é fazer o modelo responder mais certo, porque às vezes a resposta certa é muito dura ou inconveniente pra algumas pessoas. Eu tenho quase certeza que os dados extraídos dos chats de milhões de pessoas, só isso: sentimento e comprimento. Deve ajudar a criar prompts que forçam o modelo a responder “menos certo” mas “mais agradável”, incentivando o usuário a CONTINUAR falando no chat e GASTANDO MAIS TOKENS.

É o comportamento mais antigo do mundo. Todo lojista sabe disso. Todo vendedor sabe disso. Todo mundo que trabalha em serviços sabe disso. Se você for certo e direto, vai soar arrogante e o cliente não volta. É melhor soar menos certo, mas mais convidativo, agradável, prestativo, etc. E o cliente volta, porque é assim que a pessoa média funciona.

Portanto, sim: eu acho que seus dados servem pra re-alinhar o modelo depois de treinado, pra responder mais agradável. Eles nem fazem mais questão de esconder isso. Não viram o próprio Sam Altman quando falou poucos dias trás que fizeram o ChatGPT 4 responder mais amigável, com mais personalidade?

É isso que eu acho que eles estão fazendo. Tornar o modelo mais inteligente está sendo um desafio. Porque - como já venho dizendo faz 1 ano - estamos batendo no teto da curva em S. Pra continuar vendendo tokens, fazendo você voltar e se viciar em falar, não precisa ser mais inteligente, só precisa ser mais agradável.

Conclusão

Não existe LLM que vai estar 100% certo, 100% do tempo, a arquitetura fundamental IMPEDE que isso aconteça, não importa quanto mais façamos otimizações. Existe agora e sempre vai continuar existindo um componente de ENTROPIA. É essa aleatoriedade que produz texto que parece um humano falando e não um robô.

Automatizações longas e complexas demais usando essa fundação fŕagil é um ENORME erro. Claro, pra tarefas simples, curtas, focadas, ele tem uma TAXA DE ACERTO mais alta. Pra código de verdade? É SUPER baixo.

Nunca deixe um MCP fazer commits direto no seu repositório Git. Ferramentas como o Aider trazem “autocommit = true” por padrão e isso é uma enorme estupidez! Não faça isso.

Eu avisei.

Mas não tem como melhorar o código de LLMs? Talvez. 100% nunca, mas aumentar a taxa acho que dá. E pra provar que eu não sou anti-LLM nem nada disso, no próximo artigo vou tentar ensinar COMO melhorar uma LLM pra programação (com média probabilidade, não é milagre!).

• Hello World de LLM - neste artigo explico como criar um programinha simples (educativo) de chat carregando um LLM (Qwen2.5) e até como usar prompts pra que ele consiga chamar scripts/agentes e executar algumas tarefas simples como carregar arquivos locais. Eu subi o código no GitHub como Tiny-Qwen-CLI e deixei o código “sujo” de propósito pra poder testar como as LLMs conseguem (ou não ajustar esse código).
• Seu Próprio Co-Pilot Gratuito - aqui eu explico mais sobre a ferramenta Aider, que é como se fosse um Co-Pilot ou Cursor, mas gratuito e open-source. Ele não exige plugins nem IDEs. Roda no terminal e é fácil de usar. Também mostro como integrar com Ollama e subir seus próprios LLMs locais.
• Dissecando um Modelfile de Ollama - neste eu desço mais na teoria dos LLMs e explico o que é Key Sampling e os como diversos parâmetros afetam a geração de texto das LLMs, como Temperature ou Top_P. Aqui é pra desmistificar ainda mais que não existe nenhuma “mágica” em como uma LLM consegue gerar textos.

Ao longo dos últimos dias eu vim testando e postando no X minhas impressões sobre os mais diversos modelos comerciais e open source como Claude Sonnet, Gemini 2.5, OpenAI O4, Deepseek-R1, o novo Qwen3 e mais. Tem mais posts no blog além dos que mencionei acima, mas estes são os principais.

Objetivo deste post é desmistificar mais as LLMs e falar mais sobre minha experiência testando a maioria dos LLMs mais populares.

Desmistificando LLMs - 1. Benchmarks e Rankings

Quem acompanha minhas palestras e videos faz anos está careca de me ouvir falar sobre o livro “Como Mentir com Estatísticas”. E o que eu mais vejo nas centenas de posts sobre LLMs é sobre os rankings baseados em benchmarks. Este é um exemplo que viralizou ontem, no lançamento do novo modelo da Alibaba, o Qwen3:

O problema: os rankings não estão errados. Eles querem dizer o seguinte:

“Qwen 3 supera Qwen 2.5 e também outros famosos como OpenAI o1, DeepSeek-R1, Grok 3 Beta, Gemini 2.5, etc …. NOS BENCHMARKS RODADOS - e APENAS nos benchmarks rodados.”

É apenas isso. Mas 99% dos posts publica assim:

“Qwen 3 É O MELHOR PRA DESENVOLVER CÓDIGO do que Qwen 2.5 e também outros famosos como OpenAI o1, DeepSeek-R1, Grok 3 Beta, Gemini 2.5, etc”*

Os benchmarks não estão errados, quem está errado é quem interpretou que isso significa ser melhor em tudo. Vamos pra outra analogia:

“O Aluno Fulano conseguiu 99% de acerto em todos os simulados do vestibular”

A conclusão das pessoas:

“O Aluno Fulano é 99% melhor que todo mundo em tudo”

Espero que isso soe obviamente errado. Ser melhor em 1 coisa não torna ninguém melhor em tudo, mas em I.A. é assim que toda notícia de uma nova versão de LLM é publicado em posts pessoais e veículos jornalísticos. É um óbvio CLICKBAIT. E você cai.

E se você está acostumado a ouvir dessa forma, faz parecer que a cada nova versão de LLM - que é “melhor em tudo” - que o anterior, falta muito pouco ou já chegou no ponto onde sim, não precisa mais existir programadores humanos, nem matemáticos, nem engenheiros, nem médicos, afinal, a LLM é “BOA EM TUDO”.

E nada poderia ser mais longe da verdade que isso. Essas pesquisas estatísticas de ranking tem uma METODOLOGIA de testes e um pacote de benchmark fixo. Os testes são SIMPLES, pense coisas no nível “faça uma função que calcule fatorial”, “faça uma função que ordene uma lista de palavras”, “dado uma lista de palavras, encontre um em específico em tempo logarítmico”, etc. Coisas que você vê nos cursos introdutórios de ciências da computação ou Leet Code.

Esses testes são rodados MÚLTIPLAS VEZES e os “outliers” (testes onde se errou demais, ou testes onde se acertou demais, ou algo que saia da média) são descartados, é feita uma distribuição estatísticas e compilado um “número” geral genérico como “acertou 99%” ou algo assim.

Ele errou muitas vezes, mas esse ponto de dados é um outlier, e foi removido da conta. É estatisticamente irrelevante dentro da metodologia. Mas é um fato: nenhuma LLM acerta 100% das vezes nem nunca vai acertar. Eu demonstrei isso no meu post sobre Modelfiles onde eu explico que existe um fator aleatório controlado (temperatura, top_p, top_k, min_p, key sampling). E existe também normalizações e fatores aleatórios no treinamento (softmax, relu). E ainda tem fatores de otimização posterior que “arredonda” ou “trunca” as probabilidades como quantização (fp8, Q4, etc). Ou seja, existem diversos fatores de “micro erros” e aleatoriedade embutidos no processo inteiro. Nunca vai ser uma resposta “certa”, só “possivelmente uma das mais certas” e esse “possivelmente” pode variar MUITO.

Dissecando Mitos de I.A. - 2. Evolução Exponencial

Quem chegou só agora e está vendo notícias frequentes sobre lançamentos de novas versões de LLMs como o Qwen3 da Alibaba agora, o novo MiMo da Xiaomi, a versão 2.5 do Gemini, a versão 4.1 do ChatGPT, etc tem a impressão que estamos evoluindo a passos largos.

Mas a verdade é que sim, 2022 foi um marco histórico com o ChatGPT original, principalmente GPT 2. Mas de lá pra cá a evolução desacelerou. Cada nova versão não é mais visivelmente “o dobro melhor” que a anterior, a não ser em certos benchmarks, em certas condições específicas - que não condizem com a realidade. Já vou demonstrar.

Um amigo meu me lembrou sobre a evolução das tecnologias de deep learning em reconhecimento de imagens, anos antes:

• 2012 – AlexNet: Primeira grande vitória no ImageNet com 8 camadas, alcançando 84,7% de top-5 accuracy.​

• 2014 – VGG: Redes com 16–19 camadas, melhorias incrementais, mas com aumento significativo de parâmetros.​

• 2015 – ResNet: Introdução de conexões residuais, permitindo redes com mais de 100 camadas e superando desempenho humano em top-5 accuracy.​

• 2016–2017 – Inception, ResNeXt, SENet: Modelos mais complexos com ganhos marginais.​

• Pós-2018: Acurácia top-1 se estabiliza em torno de 85–88%, com ganhos marginais mesmo em modelos como EfficientNet e NasNet.

I.A. é estudada desde literalmente o início da computação moderna no fim dos anos 1930, com ninguém menos que o próprio Alan Turing ou John Von Neumann. Eu contei sobre eles aqui:

Pense um “início lento”: de 1930 até cerca de 2012 quando ImageNet e coisas como AlphaGo, GANs e coisas assim começaram a ganhar velocidade. Saímos da perna do “S” pro meio a partir dos anos 2010 e viemos acelerando até agora. Eu “chuto” que ou já estamos ou estamos caminhando pro topo do “S”, onde a curva estabiliza e desacelera. Foi isso que aconteceu com deep learning de imagens:

Lembram do AlphaGo? Eu acompanhei ao vivo. Como amador-hobista em Go, eu assisti ao vivo os jogos com me mestres sul-coreanos como Lee Sedol, na época que aconteceu, acho que 2016. Vocês devem ter visto o documentário na Netflix só agora, mas isso vem acontecendo faz anos. E agora, onde está o AlphaGo evoluindo exponencialmente? Todo mundo já esqueceu, porque o quente da moda são LLMs, que é só mais uma categoria no mundo de I.A.

A grande maioria das otimizações já foram ou já estão sendo feitas. Se fosse resumir só alguns dos milestones mais importantes desta parte da geração seria mais ou menos assim:

Todo engenheiro e cientista sabe disso: quando você não tem nada, qualquer coisa é um salto quântico. Quando você só tem 1 real, 2 reais já é “o dobro”. Quando tem 10 reais, 20 já é bastante. Mas quando chega em 20 mil, mais 100 já não adiciona tanto valor assim do que quando você só tinha 1 (ali seria 100x).

Cada nova gota de otimização agora CUSTA MUITO. Mesmo em otimização com perda de precisão (quantização) já saímos de fp32, fomos pra fp16, fp8, já chegamos em 1-bit. Não tem mais pra onde descer depois disso. Estamos no ponto onde estamos trocando precisão por performance.

Dobro de parâmetros não resulta mais em dobro de qualidade de resultado. Precisa dobrar pra ter 5%? Talvez? E não adianta continuar aumentando, o resultado começa a piorar em vez de melhorar. Por isso já pulamos pra coisas como LLMs especialistas, MoE (Mixture of Experts).

Deep thinking/Chain-of-Though/Reasoning foi um grande salto, mas só aumentar mais thnking também já não dá mais tanto resultado, na verdade, em muitos casos piora o resultado com “over-thinking”. Pensar demais não é linear também.

Aumentar contexto também não ajuda a melhorar as respostas. Pelo contrário, já vemos que a partir de um certo ponto, mais contexto atrapalha o resultado, porque a arquitetura de atenção (o grande diferencial das LLMs), tem limites. Sim, um Deepseek ou Gemini dizem suportar “1 milhão de tokens”. Mas eu já expliquei nos artigos anteriores que se trata de Sliding Window Attention como SDPA ou Flash onde a atenção é voltada só a uma PARTE desse grande contexto: ele não consegue dar atenção pra tudo o tempo todo.

Todo lugar onde dava pra colocar coisas óbvias, como caching, seja no treinamento, seja na geração, já foram colocadas. Estamos ficando sem opções aqui. E sim, novas descobertas continuam acontecendo, mas como falei, nenhuma ainda conseguiu ultrapassar os limites que sabemos que existem.

Desmistificando Mitos de I.A. - 3. Acabar com Programadores

O que eu mais detesto do hype atual são as falsas promessas de “AGI”, “Vibe Coding”, “trocar funcionários por MCPs”. Vou afirmar de novo: é tudo propaganda.

Propaganda mentirosa e falsas promessas de óleo de cobra (coisa que sempre existiu e sempre vai existir na história) DESVALORIZA a realidade as inovações que temos hoje.

“Mas o CEO da Anthropic e o tio Zuck disseram que vão substituir programadores. Microsoft e Google disseram que 30% do código deles já sai de I.A.”

Como falei antes sobre estatística. Sim: muita coisa VAI ser feita com I.A. mesmo. Não precisa de I.A. pra otimizar trabalho em várias área:

• um pedaço de pau e um bloco de argila são suficientes pra substituir a memória das pessoas. Ninguém lembra de detalhes, especialmente numéricos, permanentemente. Faz milênios que evoluímos em ajudar nossa memória com algum tipo de armazenamento externo. Seja bloco de argila, seja papel, seja post-it, seja um arquivo .txt na sua máquina.

• a primeira câmera fotográfica já removeu a necessidade de contratar um pintor de quadros pra se ter uma “selfie”.

• o primeiro computador mais primitivo já eliminou a necessidade de um prédio inteiro de matemáticos fazendo e refazendo cálculos no papel. Mesmo assim, foi desse jeito que os primeiros foguetes foram pro espaço. Já assistiu o filme Hidden Figures? Recomendo

• carros já são montados quase que totalmente por robôs, faz anos. robótica não é novidade na indústria. Hoje em dia, um tablet já substituiu caixas de supermercado e de McDonalds. Tudo isso sem precisar de I.A. URAs e botzinhos já substituíram muito de telemarketing e suporte.

Então sim, na prática, I.A. também vai substituir uma classe inteira de programadores: os de baixo valor agregado. Os que não sabem fazer muito mais que copy e paste ou cuja rotina de trabalho seja repetitivo. Se seu trabalho envolve tarefas repetitivas, é óbvio que é questão de tempo até serem automatizados, seja por I.A. seja por meros scripts. Coisa que já fazemos hoje.

O trabalho de um programador sempre foi substituir o trabalho dos outros. Você que trabalha fazendo sistema de e-commerce: você ajudou a substituir o trabalho de vendedores, vitrinistas, decoradores de loja, caixas. Você que faz sistemas de tickets e suporte, você já substituiu atendentes humanos. Você que faz sistemas de entregas, já substituiu telefonistas. Você que faz sistemas financeiros, já substituiu bancários, quem constrói agências de banco, etc.

Você, programador, sempre trabalhou substituindo o trabalho dos outros. Era questão de tempo até programadores substituírem trabalho de programadores. Chame isso de justiça poética. É só evolução mesmo. Acontece. Nada no mundo é feito pra ser estático e nem garantido.

Aqui vai a boa notícia: como sempre acontece. Ainda existem pintores, mesmo existindo fotógrafos. Ainda existem vendedores, mesmo existindo e-commerce. Ainda existe construção, mesmo não precisando tanto de lojas ou até escritórios (com home office). Ainda existe e vai continuar existindo, médicos, advogados, contadores, várias profissões. A diferença é que antes, uma empresa de contabilidade precisava de um prédio cheio de pessoas que sabiam usar ábacos e escrever planilhas em papel. Hoje um único contador que saiba usar Excel substitui um andar inteiro. Antigamente, uma empresa de publicidade era um prédio inteiro, hoje é uma pessoa que usa Canva, CapCut e Photoshop.

Programador é a mesma coisa. Antes era um prédio inteiro com piscina de bolinha roxa. Amanhã vai ser um, BOM, programador com Cursor e Aider. Quem some nessa brincadeira? Quem fazia o trabalho braçal de baixo valor agregado.

Eu avisei que isso ia acontecer. Durante 5 anos, antes de existir esta geração de LLMs e I.A. Porque é o rumo natural das coisas. Programador de curso online de fim de semana. Esse é o primeiro que vai desaparecer.

Você sabe cálculo? Sabe Álgebra? Sabe Álgebra Linear? Sabe Estatística de Probabilidade? Sabe o que é uma distribuição estatística? Sabe o que são vetores ou tensors? Sabe o que é um espaço de Hilbert? Não? Eu me precaveria se fosse você. Se todos os artigos que eu publiquei neste mês de Abril/2025 foram muito difíceis, vocês já sabem o que precisam estudar.

Minha experiência com LLMs

Eu venho usando LLMs faz 2 anos. Todo tipo de pesquisa ou código que faço passa por alguma LLM em alguma capacidade. Eu uso pesado mesmo. Meu histórico de ChatGPT é gigante.

E depois de fazer mais um intensivão pra ter certeza. Sim, o4-mini-high, Sonnet 3.7, Gemini 2.5, Qwen3, Deepseek-R1, etc são todos extremamente úteis e nenhum deles, absolutamente nenhum, consegue me satisfazer.

Vibe Coding é uma enorme bobagem. Ninguém sem conhecimentos de programação consegue fazer mais que software super simples (e cheio de bugs) usando só LLMs e prompts ou MCPs. Isso é um fato.

“Mas a evolução é exponencial, ano que vem vai ser perfeito.”

Não vai. Eu já argumentei esse ponto acima.

“Mas os benchmarks dizem que eles já conseguem fazer 99% de código perfeito.”

Também já argumentei esse ponto, sua interpretação está equivocada.

Estamos perto ou já no começo do topo da curva “S”. E eu não vejo problema nenhum nisso. Eu entendo como LLMs são feitos, entendo como são otimizados, entendo o que conseguem fazer e, mais importante, entendo o que são incapazes de fazer.

Vejam os pull requests de todas as tentativas que tentei fazer de refatoração de código e testes unitários com as principais LLMs do mercado, abertas e fechadas. O que eu vejo:

• precisa de MUITO prompt e muita instrução pra fazer eles começarem a cuspir código que funciona.
• eles parecem um estagiário, o famoso “na minha máquina funciona”. Saem cuspindo, um monte de copy e paste de código, e não re-checam se faz sentido ou se precisava. O tanto de código inútil que eles geram é assustador.
• eles repetem os mesmos erros, mesmo avisando pra não cometer.
• mesmo com “agentes”, “MCP”, mesmo rodando o código que foi gerado e dando o stacktrace de erros, eles facilmente desfocam, perdem atenção e não consguem corrigir. Mesmo re-tentando diversas vezes pra corrigir o mesmo erro. Mesmo dando dicas. Mesmo escrevendo longamento o que está errado. Rapidamente eles entram em loop. Especialmente se tiver o tal “thinking” ativado. Eles pensam demais e não resolvem.
• cansei de ver tentativa de sair mexendo aleatoriamente no código, em partes que nem pedi pra mexer, e quebrar mais do que consertar.
• nenhum deles foi capaz de gerar testes unitários que funcionam de primeira. Alguns conseguiram fazer alguns simples, depois de dar o erro e pedir pra consertar. Alguns ficam em loop de pensamento, confusos, e saem mudando sem corrigir. No final fracassam.
• Do nada começam a alucinar. O Qwen 3 mesmo, se eu tentar aumentar só um pouco temperature, de 0.1 pra 0.2 do nada começa a sair caracter chinês no meio do código, assim:

• Vira e mexe, mais de uma LLM, conseguiu a proeza de gerar teste unitário que dava erro recursivo. Isso enchia tanto o stacktrace que se eu tentava passar pra ele (mais de 12 mil tokens), isso estourava a janela de contexto e dali ele não conseguia dar atenção pra mais nada:

• como erram demais, eu fico repetidamente e exaustivamente dando chance pra ele consertar. Eu rodo o código que ele gerou, mando o stacktrace de erro, peço pra consertar. Ele mexe outra parte do código. Rodo de novo, dá erro e repito. Se fizer isso mais que meia dúzia de vezes, o contexto começa a ficar cheio, sliding window faz ele dividir atenção, ele “esquece” o que veio antes, começa a repetir o mesmo erro e fica nisso eternamente.

• não importa se suporta 8 mil tokens, 30 mil tokens, 100 mil tokens ou 1 milhão de tokens no contexto. Isso não influenciou a qualidade do código e nem melhorou essa rotina de repetição de erros. Ele nunca consegue dar atenção pra tudo.

• não adianta tentar tunar o key sampling. seja com temperature 0, 0.1, 0.6. Só faz ele errar um pouco depois ou um pouco antes, mas ele rapidamente erra e rapidamente fica incapaz de corrigir os próprios erros. Ferramentas como Aider pegam o código que ele sugeriu e grava em cima do arquivo de código de verdade. Várias vezes, por encher demais o contexto, ele começa a “esquecer” e apagar trechos do código. Ainda bem que GIT existe, porque várias vezes precisei dar git checkout pra voltar pro começo. Se você não checa, cuidado, ele apaga código ou sobrescreve com bobagem, e isso é frequente.

• deep thinking/reasoning/chain-of-thought, seja lá como você prefere chamar, só significa que ele fica pensando em excesso e enchendo o contexto de linguiça, comendo seus tokens. Se sua API comercial, cuidado: você vai acabar com seus créditos muito rápido e o resultado não é significativamente melhor. São casos isolados onde isso ajuda. Eu recomendo deixar desligado por padrão e ligar só em alguns casos especiais.

E veja: meu projeto de exemplo é ridículo: são 5 arquivos. 4 deles tem menos de 100 linhas de código, o maior tem 400 e tantas linhas. Um projeto de verdade, grande, são MILHÕES de linhas de código. Não cabe em nenhum contexto de nenhum Gemini ou Deepseek. E mesmo se coubesse, só deixaria ele mais confuso. A boa prática em qualquer ferramenta é dar o mínimo de arquivos pra ele. E isso restringe os casos de uso a refatorações locais e isoladas, jamais coisas como renomear uma classe ou função que é usada em centenas de arquivos. Pra isso, continue usando seu IntelliJ.

Nenhum modelo que testei é perfeito. Alguns modelos se dão um pouco melhor em alguns casos. Na primeira tentativa que fiz com o Gemini 2.5, ele até que conseguiu executar as tarefas que pedi. Não deu um código maravilhoso, mas pelo menos não quebrou nada.

Na segunda vez, dei git reset --hard e re-comecei, com os mesmos arquivos e os mesmos prompts. Dessa vez foi extremamente decepcionante. Ele quebrou o código principal na refatoração e foi incapaz de terminar um teste unitário que funcione mesmo eu forçando ele várias vezes. Desisti pelo cansaço.

Na terceira vez, ele deu resultado diferente, melhorou um pouco o código e ele conseguiu terminar o mesmo teste. Mas também precisou de algumas rodadas de teste quebrado, dar stacktrace e mandar corrigir erros óbvios. E quanto eu digo “óbvio” é ele consertar um mock que ele mesmo colocou sem precisar.

E isso é consistente em todos os outros modelos. Se eu só rodo uma vez, tenho uma impressão. Por exemplo, que Claude é melhor que Qwen3. Mas se eu rodo de novo, o mesmo teste, agora o Claude me decepciona e o Qwen3 passa na frente. Nunca tem um vencedor objetivamente melhor. Estão todos mais ou menos na mesma posição e ficam mudando no ranking dependendo de quantas vezes você repete exatamente o mesmo teste, com o mesmo código e os mesmos prompts.

E quem fica repetindo a mesma coisa? Ninguém. Todo mundo aceita a primeira resposta. E a primeira resposta pode estar BEM errada. Num nível óbvio de errada. Se aceitar automaticamente, vai inserir lixo no repositório. E esse é meu problema com coisas como MCP ou agentes: se deixar tudo no automático e pedir coisas como “pegue todos os arquivos de código deste diretório e corrija todos os bugs”. Ele vai, com toda certeza, gerar mais bugs, apagar código, sumir com arquivos e deixar o repositório final num estado pior do que antes.

Vibe Coding puro, com nenhuma interação de um programador, não funciona. Eu testei todos os modelos principais. Nenhum foi capaz de passar testes simples. Nenhum vai ser capaz de passar por testes maiores de verdade. Não sem muita interação de um bom programador pra rejeitar os erros e mandar repetir, ou corrigir manualmente o que saiu errado.

E adivinhem: codificador que só sabe fazer copy e paste do stackoverflow (e agora do ChatGPT), é incapaz de reconhecer muitos desses erros. Então em vez de ajudar, ele pode piorar.

Pra mim, que sei exatamente o que eu quero, os erros são óbvios e eu automaticamente rejeito. E eu rejeito o que toda LLM faz mais do que aceito. Muitas vezes eu só pego um trecho do que ele sugeriu e descarto todo o resto. Esse é o dia a dia de verdade. Todo mundo que diz o contrário não fez código mais complicado do que um Hello World.

Por que você acham que todo exemplo de “uau, veja a LLM fazendo código sozinha” sempre é fazendo uma função de fatorial? Ou uma página web tosca? Porque é só isso que ele consegue fazer mesmo. Nenhum exemplo de MCP que eu vi até agora me deixou impressionado. Foi tudo fumaça. E você foi enganado pela propaganda.

Agora você sabe.

Como faz pra saber mais e não ser enganado? Comece aprendendo os fundamentos. 1 ano atrás eu fiz vários videos explicando como LLMs funcionam. Você já deveria ter assistido:

E pra virar programador que não vai ser substituído pela I.A.? É pra isso que eu fiz meu canal. Quando tudo que eu disse virar comum pra você, parabéns, você tem boas chances de sobreviver.

O pessoal do Wisecrack sempre consegue me arrancar um sorriso. Me dão esperança de que ainda existem pessoas com bom senso nesse mundo. Este texto é inspirado naquele vídeo e numa série de pensamentos complementares que fui juntando.

Como engenheiro, vivo pasmo com o que somos capazes de criar. Ninguém imaginaria que uma das invenções mais fantásticas da humanidade, a internet, junto dos seus maiores sucessos, pudesse virar arma de destruição em massa. Falo do acesso móvel onipresente e das redes sociais capazes de reunir um número absurdo de pessoas ao mesmo tempo.

Esse caso está longe de ser o único, mas serve de exemplo. Há poucos dias, fui pego de surpresa por uma notícia aparentemente pequena. James Gunn, o querido diretor de dois dos maiores sucessos do MCU com seus Guardiões da Galáxia, foi demitido por causa de tweets que escreveu havia dez anos.

Não estou aqui para julgar o mérito dos tweets nem se o pedido de desculpas dele foi suficiente.

Na verdade, só de dizer que sou neutro já sou automaticamente julgado como favorável. Esse é o problema.

Nos últimos dias, vimos páginas e contas de direita sendo deletadas do Facebook. Faz parte do esforço contínuo da plataforma para combater “fake news”, que de fato é um problema contemporâneo. Portais de notícia viraram fábricas de clickbait, exatamente como o vídeo do Wisecrack descreve.

Mas quem decide o que é “fake news”? O que “ofende” um grupo barulhento que gera cliques. Portanto, precisamos banir o outro lado.

Isso me lembra uma frase clichê de O Senhor dos Anéis que sempre ressoou em mim. Quando a Sociedade tenta atravessar Moria, Frodo lamenta para Gandalf:

“Que pena que Bilbo não apunhalou aquela criatura vil quando teve a chance!”

E Gandalf responde:

“Pena? Foi a Pena que deteve sua mão. Pena e Misericórdia: não ferir sem necessidade. E ele foi bem recompensado por isso, Frodo. Pode ter certeza de que sofreu tão pouco com o mal e escapou no final justamente porque começou sua posse do Anel dessa forma. Com Pena.”

E então conclui:

“Merece! Eu diria que sim. Muitos que vivem merecem a morte. E alguns que morrem merecem a vida. Você pode devolvê-la a eles? Então não seja tão ansioso para distribuir a morte em julgamento.

Pois mesmo os muito sábios não conseguem ver todos os fins. Não tenho muita esperança de que Gollum seja curado antes de morrer, mas existe uma chance. E ele está ligado ao destino do Anel. Meu coração me diz que ele ainda tem um papel a cumprir, para o bem ou para o mal, antes do fim; e quando isso acontecer, a pena de Bilbo poderá reger o destino de muitos, inclusive o seu.”

Voltando ao Gunn: o que me surpreendeu não foi a republicação dos tweets nem a indignação pública (obviamente, nenhuma pessoa sã endossa literalmente o conteúdo específico). O que realmente me impressionou foi a velocidade absurda com que uma megacorporação do tamanho da Disney respondeu com uma guilhotina, destruindo uma grande carreira em questão de horas.

Me lembra sentenças públicas igualmente rápidas, sem julgamento, sem devido processo. De novo, não estou defendendo essas pessoas, mas lembro dos casos James Damore vs. Google, Brendan Eich vs. Mozilla e James Watson vs. Nobel.

E a maioria de vocês, ou dos seus amigos, diria: “claro que foram expulsos, são pessoas ruins, temos que nos policiar para remover esses vilões do nosso meio.”

Será que devemos?

Você consegue devolver o futuro deles se estiver errado? O que te dá o direito de ser juiz e júri?

Cuidado. Quando provocada, uma pessoa razoável e normal busca o diálogo em privado, como qualquer sociedade civilizada aprendeu a fazer. Mas as redes sociais motivam as pessoas a fazerem o pior: expor publicamente.

Isso é formação de manada. Bullying puro e simples. Sofri bullying a vida inteira, sendo minoria japonesa num país ocidental, e sei exatamente o quanto dói. É por isso que jamais revido com bullying.

Se você expõe alguém publicamente, não está praticando “justiça”. Você é simplesmente um bully. Independente do assunto.

Você já leu o cabeçalho dos meus perfis no Facebook e no Twitter? Diz:

“Eu desaprovo o que você diz, mas defenderei até a morte o seu direito de dizê-lo.” — Evelyn Beatrice Hall.

E eu acredito nisso de verdade.

Nunca vou humilhar alguém publicamente. Só covardes fazem isso. Envergonhar alguém em público tem um único propósito: mobilizar a massa, transformar o rebanho em tropa de choque para executar alguém em praça pública e, assim, fazer valer o próprio ponto sem precisar defendê-lo.

“Mas eu tenho o direito de não ser ofendido.”

Não. Não tem.

Outro filme que comentei anos atrás, e do qual cortei um trecho para publicar aqui, é a obra-prima de Miloš Forman, O Povo Contra Larry Flynt, produzida por Oliver Stone.

O filme conta a história do fundador da revista pornográfica Hustler. Um sujeito desprezível por praticamente qualquer critério.

Mas esse é exatamente o ponto. Larry fez coisas que a maioria de vocês condenaria. Não só publicar pornografia, mas satirizar figuras públicas com piadas de péssimo gosto. Piadas, ainda assim. O trecho que mais me impactou foi a ideia de que ninguém tem o direito de não ser ofendido. É uma questão subjetiva, sem lugar num tribunal, porque gosto não se define juridicamente.

“Senhoras e senhores do júri, vocês ouviram muito hoje, e não vou revisitar tudo isso, mas precisam entrar naquela sala e tomar algumas decisões. Mas antes, há algo que precisam saber. Não estou tentando sugerir que vocês deveriam gostar do que Larry Flynt faz. Eu não gosto do que Larry Flynt faz. Mas gosto de viver num país onde você e eu podemos tomar essa decisão por conta própria. Gosto de viver num país onde posso pegar a revista Hustler, lê-la, ou jogá-la no lixo se for lá que acho que ela pertence.”

Qualquer pessoa tem o direito de fazer e dizer o que quiser, desde que não cause dano real a outra pessoa. É uma linha tênue, porque meus direitos devem terminar onde os seus começam.

“Se a Primeira Emenda vai proteger um lixo como eu, vai proteger todos vocês.” — Larry Flynt.

Mas como isso não pode ser resolvido nos tribunais, pessoas radicais tomam a lei nas próprias mãos usando a arma mais poderosa já criada: as redes sociais. Elas conseguem reunir um júri enorme em minutos e decretar a execução pública. É como dar uma arma carregada para uma criança.

Isso é território de Inquisição. Galileu foi julgado e condenado porque ofendeu a sociedade católica ao afirmar que a Terra e os planetas giram em torno do Sol, e não o contrário. Parece trivial hoje, mas era um escândalo monumental na época. Havia gente disposta a morrer para não aceitar essa afirmação ofensiva. O tema estaria em alta no Twitter dos anos 1600, e a execução pública seria exigida em minutos.

Essa justificativa do “estou ofendido” é o que levou, em última análise, a assassinatos como os de Luther King, JFK e Lennon, à prisão de Gandhi e ao genocídio dos judeus. Intolerância.

Se não ser ofendido é o objetivo máximo, a intolerância vira o único caminho, e o assassinato da Liberdade, a pior consequência.

Toda atrocidade da humanidade começa com o comportamento de manada em torno do “eu não deveria me sentir ofendido.”

Essa é a história por trás de Fahrenheit 451, que o Wisecrack explica bem. Em dado momento, as pessoas simplesmente começaram a criar câmaras de eco. Cada feed do Twitter e cada linha do tempo do Facebook são, por definição, câmaras de eco. Você só recebe conteúdo meticulosamente curado por machine learning, configurado para cuspir posts que não vão te ofender e jamais vão desafiar seus pontos de vista.

Você cria e vive numa bolha, e fica indignado imediatamente quando sua realidade é desafiada por qualquer ideia que provoque reflexão. Você se limita ao seu status quo personalizado e estreito.

É mentira quando você diz “sou de mente aberta” mas fica expondo pessoas o tempo todo e reclamando de tudo que te ofende. Você não é de mente aberta. Não dá pra ter o bolo e comer o bolo também. Pelo menos admita a verdade: que você é de mente fechada e intolerante.

Ao contrário do que muitos acreditam, a internet deveria nos libertar dos governos, das instituições autoritárias e dos grandes veículos de mídia que supostamente controlavam o ponto de vista das massas.

Deveríamos ter acesso a um leque mais amplo de conhecimento, sem fronteiras, sem preconceito, o que nos ajudaria a avançar mais rápido para o futuro, para mais inovação.

Inovação, por definição, é um desafio ao status quo. Você não consegue inovar e agradar todo mundo ao mesmo tempo. Isso é impossível. Do contrário, é só mais do mesmo.

A invenção do fogo desafiou a natureza, o heliocentrismo questionou Deus, a teoria da evolução por seleção natural desafiou a alma humana.

As redes sociais pegaram uma internet livre e descentralizada e a colocaram numa coleira bem apertada, controlada por “Influencers”. Gente de puro carisma, sem retidão e muito menos sabedoria. O carisma é o que atrai grandes quantidades de seguidores. O efeito de rede é perverso.

Deveríamos estar todos juntos, colaborando para o bem da humanidade, independente de raça, geografia ou inclinações políticas.

Fique atento: você está caindo nas Oito Etapas do Genocídio. Veja:

1. Classificação: As pessoas são divididas em “eles e nós”.
2. Simbolização: “Quando combinados com ódio, símbolos podem ser impostos a membros relutantes de grupos párias…”
3. Desumanização: “Um grupo nega a humanidade do outro. Os membros são equiparados a animais, vermes, insetos ou doenças.”
4. Organização: “O genocídio é sempre organizado… Unidades especiais do exército ou milícias são frequentemente treinadas e armadas…”
5. Polarização: “Grupos de ódio disseminam propaganda polarizante…”
6. Preparação: “As vítimas são identificadas e separadas por sua identidade étnica ou religiosa…”
7. Extermínio: “É ’extermínio’ para os assassinos porque eles não acreditam que suas vítimas sejam plenamente humanas.”
8. Negação: “Os perpetradores… negam que cometeram qualquer crime…”

Esse é o modus operandi nazista original, e você está perpetuando essas etapas. Não sou judeu, mas admiro e respeito profundamente sua história e resiliência. Já fui ao Instituto do Holocausto oficial em Yad Vashem, em Israel, e também ao de Washington D.C., porque respeito as lições que deixaram para trás. Era nosso dever não deixar a história se repetir.

Mas tal é o poder da ideologia cega e da liderança de celebridades carismáticas.

Tivemos líderes carismáticos fazendo coisas boas e ruins, carismáticos de qualquer forma. Para cada Lincoln ou Churchill, tivemos um Stalin ou um Castro.

O mais difícil é que só conseguimos saber, com clareza, que algo deu horrivelmente errado olhando para trás, pela História. Não existe um “bem” versus “mal” em preto e branco. Você sempre acha que está fazendo um excelente trabalho ao seguir pessoas carismáticas que parecem promover apenas o bem-estar de um grupo minoritário.

Pergunte a si mesmo: você está seguindo alguém altruísta, capaz de tratar o outro com mais humanidade do que recebeu? Ou isso soa mais como vingança egoísta e acerto de contas? O ódio é sempre a matéria do mal. Uma pessoa justa não imita aquilo contra o qual diz lutar. Qualquer um que defenda “vamos fazer com eles o que fizeram conosco” é provavelmente o Mal. Você cita gente como Gandhi. Não aprendeu nada com o que ele ensinou a vida inteira?

Todo Fidel, todo Mussolini, todo Hitler realmente acreditava que estava lutando pelo bem-estar do seu povo. Todo nazista agiu acreditando que estava fazendo a coisa certa pelo futuro dos seus filhos e filhas, que os sacrifícios valeriam a pena. Que eram Nobres por matar pessoas.

Nunca houve uma plataforma melhor para transformar pessoas em manadas irracionais do que agora. Há YouTubers com milhões de seguidores a mais do que qualquer Hitler jamais teve.

E para piorar, formamos o consenso online de que as pessoas têm um direito mágico e inerente de “nunca serem ofendidas”. Não podem ser ofendidas por tweets de 200 caracteres. Isso é pecado capital, e o perpetrador deve morrer. Pedido de desculpas não basta. A polícia do pensamento chegou a tal ponto que um único tweet fora de contexto basta para julgar e executar a vida de uma pessoa, sem recurso, sem liberdade condicional.

É fascinante ver como uma série de tecnologias e inovações que deveriam ampliar a liberdade de todos acabou se tornando a arma de destruição em massa mais potente já criada. E não precisou de um novo Hitler para isso.

O fim do mundo não precisa ser um evento físico catastrófico, como uma explosão nuclear. Acho que a destruição do próprio tecido da sociedade é ainda pior. Não é um grande ditador malvado que vai matar a Liberdade, são as pessoas que não a merecem. É muito mais nefasto e pode ser ainda mais devastador.

Essa é a lição: nenhum Omar Bashir, Bashar Al-Assad ou Nicolás Maduro será, sozinho, responsável por destruir a sociedade.

Todo malfeitor da história fez o que fez “em nome do povo.”

E tudo começa com “eu não deveria ser ofendido.”

De curiosidade, perguntei lá se alguém conhecia empresas ou pessoas atuando nessa área aqui no Brasil, e a lista que recebi ficou bem interessante. Vale compartilhar as recomendações com todo mundo.

• Auctus - ICO de uma alt-coin
• Original My - proof-of-authenticity
• Laivon - parece que desenvolve apps mobile e alguns deles são trackers de cryptocurrencies
• OpenDime - mais um hardware stick pra wallet - dizem que tem brasileiros trabalhando lá também
• HugPay - uma forma de fazer remessas de/para o exterior sem precisar de conta bancária, com parceria com lotéricas (boa ideia)
• Blocko Ventures - não entendi bem se são uma empresa de serviços ou investidores em soluções com blockchain
• Kriptacoin - é mais uma alt-coin (vide comentários)
• BlinkTrade - parece uma infra para exchange (acho que a Foxbit e outras talvez usem - não confirmei isso) e foi fundada por brasileiros
• Stone Pagamentos - disse que está ajudando empresas a aceitar pagamentos em cryptocurrencies.

Quero conhecer mais empresas e profissionais brasileiros no ecossistema de bitcoin e cryptocurrencies em geral. Estou procurando em especial palestrantes que dominem o assunto e estejam fazendo coding hands-on, para palestrar (em inglês) na conferência que estou organizando, a THE CONF. Se souberem de alguém, mandem na seção de comentários.

Cheguei a pensar em escrever sobre blockchain ou cryptocurrencies, já que andei estudando e investindo bastante. Mas tudo que você precisa saber já está acessível em inúmeros blogs e sites, em inglês e em português, e não faz sentido explicar tudo de novo.

O que me interessa é saber onde estão as maiores dúvidas das pessoas sobre o assunto, para tentar explorar algum aspecto específico. Comentem sobre isso também.

Uma das mais populares responde à pergunta “Qual é a coisa mais difícil que você faz como engenheiro de software?”. Escrevi algo parecido em português no post “Estimativas são Promessas. Promessas devem ser cumpridas.”.

Em resumo: você nunca consegue dar uma estimativa “correta”. Se conseguisse, não seria uma “estimativa”, seria uma “previsão”.

Vamos assumir que não temos poderes de precognição nem bolas de cristal para prever o futuro.

Estimar algo é “chutar” o valor de alguma coisa. É sempre um chute, a mesma coisa que uma avaliação. Como todo chute, nunca pode ser considerado “correto”: é só um candidato provável dentro de uma faixa infinita de valores possíveis.

Não existe nenhuma conexão entre um chute e o resultado. Entenda essa verdade simples: dizer que algo pode acontecer não FAZ com que aconteça.

Estimar que vai chover amanhã não FAZ chover. Estimar o resultado do Super Bowl não FAZ o jogo acontecer daquele jeito. Não há correlação entre uma estimativa e o resultado real.

Eu disse nos artigos mencionados que “Estimativas são Promessas”. A intenção era provocar uma reação, porque a maioria das pessoas assume que estimativas jamais podem ser promessas, justamente pelo que acabei de explicar.

O que torna uma promessa especial é que, ao prometer algo, espera-se que você AJA para realizá-la.

Ninguém que não tem “skin in the game” deveria dar estimativas.

Se você não é um jogador ativo no jogo, não deveria dar chutes. Do mesmo jeito que ninguém faz promessas em nome de outra pessoa.

Dá pra fazer promessas críveis e cumpri-las? Dá, mas primeiro você precisa entender mais algumas verdades sobre a realidade.

Você provavelmente já leu muitos artigos explicando metodologias e técnicas de gestão de projetos. A maioria consegue explicar os “o quês” e os “comos”, mas como sempre, falha nos “porquês”.

Por que precisamos dessas metodologias? Por que elas são necessárias? Por que funcionam? Que mecanismos ocultos elas colocam em movimento?

O que diferencia as técnicas Ágeis da homeopatia ou de um clichê barato de autoajuda?

É sempre sobre Pareto

Não existe escopo de projeto preciso. Existe um limite para adicionar detalhes, e depois dele você só tem retornos decrescentes.

O nível mais preciso de detalhe que o escopo de uma funcionalidade pode ter é o próprio código. E isso importa: as linhas de código NÃO são o produto final. O que os usuários experimentam de fato é a execução desse código em tempo de execução.

A programação em si é o blueprint de verdade. Os diagramas, os casos de uso, as user stories e tudo que vem antes da programação são só rascunho, um esboço.

Um arquiteto ou designer ingênuo pode achar que diagramas detalhados, documentos de casos de uso e slides bonitos de PowerPoint valem o mesmo que um blueprint de engenharia. Eles valem menos: são o equivalente a um rabisco no guardanapo. Voláteis e, na prática, quase inúteis.

“Mas a programação não é a mesma coisa que a fase de construção, colocar tijolo sobre tijolo?” NÃO, não é isso que um programador faz. Empilhar tijolos é trabalho do interpretador da linguagem ou do compilador que gera o binário executável.

Essa é a metáfora que deixa os não-programadores malucos. Na engenharia, a construção em si é a parte mais cara e demorada. Na programação, a parte cara é criar o blueprint (escrever o código), e a “construção” é trivial: só compilar, o que é automático.

Do mesmo jeito, o escopo de um projeto é só um conjunto de esboços. Precisamos abandonar a ideia de que vai existir um escopo “completo”. Não dá pra dizer “100% do escopo” ou “escopo fechado”, porque o escopo de um projeto de software é, por definição, sempre incompleto.

Além disso, sustento que cerca de 80% desse tal “escopo”, o que prefiro chamar de esboço, é praticamente inútil para a maioria das atividades dos usuários finais: a seção administrativa, as páginas institucionais que ninguém lê, processos complicados de cadastro e por aí vai.

Por isso toda lista de funcionalidades precisa ser priorizada. Você costuma se virar com 20% das funcionalidades, que é o que as pessoas querem dizer com “MVP” ou “produto mínimo viável”. Entregue o mais cedo possível, colete feedback dos usuários e refine o resto do “esboço” que você chama de backlog.

Então, em vez de mirar numa proposição de tudo-ou-nada, procurando equações complexas e estúpidas para calcular uma estimativa “precisa” de um esboço incompleto, assuma que dá pra entregar CEDO os primeiros 20% que realmente importam e descubra o resto em iterações.

É isso que chamamos de “Ágil”, aliás.

Ágil é sobre Gestão de Riscos

As pessoas assumem que Agilidade é gerenciar os próprios instrumentos de gestão: o backlog, os rituais, as métricas.

Ter instrumentos parecidos com Ágil não te torna Ágil.

Ser Ágil é manter o Risco sob controle.

Em vez de tratar projetos como uma proposição de tudo-ou-nada, comece a pensar como um investidor pensa no seu portfólio de ações. Você não espera que o portfólio inteiro dê lucro; parte do princípio de que alguns ativos vão ter desempenho abaixo do esperado. Como não sabe quais, você dilui o risco.

Tentar prever o mercado de ações é um exercício de futilidade.

Tentar prever a implementação exata de um projeto, ainda mais os longos, também é um exercício de futilidade.

Então você precisa lidar com a incerteza do jeito certo: tornando-se Antifrágil.

“Algumas coisas se beneficiam de choques; elas prosperam e crescem quando expostas à volatilidade, aleatoriedade, desordem e estressores, e adoram aventura, risco e incerteza. No entanto, apesar da ubiquidade do fenômeno, não existe uma palavra para o exato oposto de frágil. Vamos chamá-lo de antifrágil. A antifragilidade vai além da resiliência ou robustez. O resiliente resiste aos choques e permanece igual; o antifrágil melhora.” - Nassim Taleb

Em vez do exercício absurdo e inútil de tentar prever incertezas e eventos aleatórios, você faz a coisa sensata: assume que Cisnes Negros existem e que você não consegue prevê-los. E aí se prepara para a incerteza da única forma razoável, que é não tentar prevê-los.

Exponha os pequenos erros cedo e corrija com frequência. Implementar tudo numa caixa-preta e fazer um deploy Big Bang é o caminho mais fácil para o fracasso. Entregar sempre, expor os bugs e corrigi-los constantemente é aceitar que erros vão acontecer e ganhar força no processo.

Uma Metáfora Melhor

Imagine que você, seja o cliente não-programador, seja o programador que não faz ideia de como explicar o processo para esse cliente, tem um alto-forno de minério de ferro para gerenciar.

O problema desses fornos é que, se você aquecer demais, eles podem explodir na sua cara. Se esfriar demais, o minério endurece.

Seu trabalho é adicionar carvão ao forno, e você decide o ritmo. Rápido demais, fica quente o bastante para explodir. Devagar demais, o fogo apaga e você perde o forno.

Agora tente estimar uma entrada constante de carvão para manter o forno em bom estado.

Não dá.

A saída mais fácil é instalar um termômetro que acompanha a temperatura atual do forno.

Você fica seguro dentro de uma certa margem de temperatura e acelera ou reduz a entrada de carvão consultando o termômetro o tempo todo.

O TEMPO TODO.

É isso que a “Velocidade” do Ágil (ou qualquer simulação de Monte Carlo mais sofisticada) realmente é: um termômetro.

Se a Velocidade está alta demais, seu time provavelmente está fazendo hora extra ou entregando código de qualidade inferior. Isso vai dar problema: ou o time estoura rápido demais, ou o código acumula dívida técnica rápido demais e você não vai conseguir pagar. Mantido esse ritmo, a Velocidade despenca até parar (o forno explode).

Se a Velocidade está baixa demais, seu time está enrolando, seu backlog é um lixo que ninguém entende nem depois de 10 horas de reunião, ou você deixou a Velocidade subir demais e agora está pagando a dívida técnica, ou seu time está morto de burnout (o fogo apagou).

Você quer manter a Velocidade estável, constante. É disso que se trata ser Ágil: ficar de olho no termômetro e responder.

O Triângulo de Ferro dos Projetos

Bem-vindo ao Triângulo de Ferro da Gestão de Projetos.

Repita comigo: se eu quero travar o tempo, o custo e o escopo, sou um idiota.

Repita de novo.

Você deve travar tempo e custo. Se leu até aqui, sabe que nunca consegue travar o “escopo”: só dá pra engordá-lo, e nem sempre torná-lo mais valioso. Por isso sempre digo que a definição de um Product Manager ou Product Owner é ser o guardião do ROI (Retorno sobre Investimento).

Por quê?

Porque o Triângulo de Ferro tem o seguinte corolário:

• Se quer rápido e bom, não pode ser barato
• Se quer rápido e barato, não pode ser bom
• Se quer bom e barato, não pode ser rápido

Isso é uma Lei, não tem como contornar. Escolha o seu.

Como Cumprir Promessas então?

Com essas 3 verdades em mãos:

• Não dá pra ter tudo ao mesmo tempo (barato, rápido e bom)
• Você está gerenciando a temperatura do forno
• Você só precisa de 20% do “esboço” que chama de “escopo”

Sim, qualquer desenvolvedor experiente consegue te dar uma estimativa de “ballpark”. Uma estimativa de ballpark é assim:

• 1 mês (talvez 1 mês e meio, mas com certeza menos de 2)
• 3 meses (mais de 2 meses, menos de 6)
• 6 meses (mais de 4 meses, menos de 9)
• mais de 6 meses, provavelmente menos de 1 ano

Nem tente granular mais que isso. É inútil.

Trave o tempo. E trave o custo (o número de desenvolvedores vezes a taxa horária vezes o total de horas estimadas). Só isso.

Agora anote o que o cliente chama de “escopo” como user stories num backlog e peça pra ele priorizar.

Comece as iterações. Depois de cada uma, faça deploy num ambiente de staging. Não-programadores, atenção: SEMPRE garanta que o programador que você contratar entregue versões testáveis das stories numa URL pública que você possa visitar e testar.

Se o programador recusar isso ou vier com desculpa: DEMITA.

Se o programador, a empresa ou seja lá o que for te prometer um preço de “escopo fechado”, prometer fazer tudo e você acreditar, você é ingênuo demais.

Acha graça em jogar esse jogo idiota de “vou fingir que sei a verdade e você vai fingir que acredita no que estou dizendo”?

Nenhum profissional sério tem tempo pra jogos idiotas. A única coisa honesta que alguém pode dizer sobre qualquer projeto de software é: “com base na minha experiência, acredito que o ballpark para esse tipo de projeto é de X meses, dados os pressupostos Y e Z”.

Você não precisa acreditar nele. Só precisa começar a verificar o termômetro. Qualquer não-programador consegue avaliar a qualidade da entrega a partir das entregas frequentes das funcionalidades priorizadas.

“Mas e se depois de 2 semanas eu não gostar do resultado?” Simples: DEMITA.

E às vezes “demitir” nem é a palavra certa. Às vezes o relacionamento é difícil e o melhor é seguir caminhos separados.

Você precisa aceitar perder 2 semanas, ou qualquer período curto, como parte da Gestão de Riscos. É melhor aceitar perder 2 semanas do orçamento do projeto do que acreditar cegamente em alguém por 6 meses e perder o orçamento inteiro e mais um pouco.

Pareto de novo: Agilidade é sobre Gestão de Riscos. Você aceita que perder 20% do orçamento está de bom tamanho e joga com isso. E tudo bem, porque você só precisa de um pouco mais de 20% do esboço vago que chama de escopo.

Viu o que fiz com a matemática aqui?

Paramos de jogar o faz-de-conta e passamos a gerenciar de fato os riscos do projeto. Você colabora no termômetro equivalente, que combina o backlog priorizado (a escala) e a velocidade (a temperatura), e fica de olho nas entregas parciais no ambiente de staging.

Conclusão

Então sim, Estimativas devem ser levadas tão a sério quanto Promessas. Você consegue dar Estimativas razoáveis desde que consiga gerenciar os Riscos e o Cliente aceite as regras do jogo: não existe “escopo fechado e completo”, prioridades primeiro, e testar e aceitar funcionalidades entregues toda semana.

A ideia por trás das Promessas é que você precisa GERENCIAR para cumpri-las. A melhor forma é parar com frequência, reavaliar e seguir. Parece perda de tempo, mas é assim que você evita desperdiçar tempo de verdade.

Se você não tem skin in the game, dê um passo atrás.

A Velocidade deve ser mantida estável, num ritmo previsível. Use a variância como sinal de estar rápido demais ou devagar demais, ajuste a outra variável, meça de novo e siga. Igual a um termômetro de forno.

Existem várias versões de “termômetros”, do Evidence Based Scheduling do Joel Spolsky às sofisticadas simulações de Monte Carlo e outros processos estocásticos (todos são termômetros, e NÃO ferramentas de estimativa).

O que te impede de fazer isso é usar as metáforas e as referências erradas.

Em vez de procurar metáforas equivalentes na construção civil, nas fábricas e em outras montagens de “hard”-ware, olhe para outro lugar, onde você vai encontrar processos de “soft”-ware.

Músicos têm prazos. Pintores têm prazos. Coreógrafos têm prazos. Esportes têm prazos. Laboratórios de pesquisa têm prazos. Como eles cumprem? Verificando constantemente o estado atual, comparando com os objetivos, avaliando se o que fazem está funcionando e mudando o que não funciona.

Hollywood tem prazos. Tem variáveis muito piores de controlar do que qualquer projeto de software que você vá encontrar, e ainda assim entrega. E lucra.

Aceite que você não controla todas as variáveis e pare de tentar. Pense nos mercados financeiros. Um dia o Ethereum dispara 4.000% e no dia seguinte despenca num flash-crash.

Não tente ficar resistente ou resiliente. Prepare-se para ser Antifrágil.

Mas você é uma pequena startup de tecnologia ou uma equipe pequena dentro de uma grande corporação. Por onde começar?

A recomendação é simples: faça a menor coisa que funciona primeiro. Sempre. Claro, evite o “rápido e sujo” ao máximo. Mas não seja paranoico nem exagere na engenharia.

Super-engenharia é tão cara quanto fazer as coisas de forma “suja”.

Adicione “Tempo” à sua equação

O erro mais comum que a maioria das pessoas comete é ignorar a variável “Tempo”.

Todo mundo vai a conferências de tecnologia, lê posts badalados ou assiste screencasts chamativos. A conclusão errada que tiram é: “a Netflix usa isso, então deve ser bom pra mim, porque eu quero me tornar a Netflix”.

O pressuposto falso é que a Netflix, ou o Google, ou o Facebook, ou o Spotify, é um sistema estático e sempre funcionou da forma como divulga hoje.

As pessoas esquecem que toda empresa unicórnio teve um dia 1. E no dia 1, elas não usavam microsserviços. Não tinham React.js. Não tinham Go nem Elixir. Algumas nem tinham bons programadores de início. A Netflix começou como um serviço de aluguel de VHS, lembra? O Google começou num quarto de dormitório universitário com componentes de hardware montados num rack de Lego.

Imagine que você é fã de uma celebridade. Essa celebridade tem uma Lamborghini. Você quer ser como essa celebridade um dia. O que você faz? Compra a mesma Lamborghini que ela tem?

Se você fizer isso, a única coisa que vai conseguir é uma DÍVIDA ENORME para pagar.

Pare de invejar a Lamborghini do rico.

Dívida (Técnica)

Esse não é um termo novo nem um tema novo. Cada decisão que você toma em programação é um compromisso entre o que o “futuro ideal” deveria ser e o que você consegue fazer agora. Tomar empréstimo para comprar a Lamborghini equivalente cedo demais, e você vai ter que lidar com uma Dívida (Técnica) impagável. Você vai travar, vai parar e não vai fazer nada além de pagar essa dívida daqui pra frente.

Você quer “codar mais rápido”, então pula a escrita de testes automatizados, porque acha que vai te atrasar. E você está certo. O desenvolvimento orientado a testes não te deixa mais rápido de início, e nem deveria. Ele protege seu eu futuro do seu eu presente e evita que você acumule Dívida Técnica.

De novo: você esqueceu a variável “Tempo”.

Você escreve e entrega rápido no primeiro mês. Depois que a primeira versão está em produção, você começa a ser obrigado a pagar a dívida. Sua produtividade cai. Bugs de regressão aparecem. Cada nova funcionalidade que você tenta adicionar quebra algo de forma inesperada. Como não tem testes automatizados, você fica corrigindo as mesmas coisas várias vezes. A dívida vai cobrar, e você vai pagar. De um jeito ou de outro.

Suítes mínimas de testes são como um Seguro. Você não precisa dele agora, no dia 1. Mas no dia 100 você vai ficar feliz que tem.

Fazer microsserviços demais no dia 1 é dívida. Parece ótimo estar fazendo aquela coisa bacana que você leu num blog. No dia 100, com sua equipe de 3 pessoas e uma dúzia de microsserviços, você não vai fazer nada além de pagar a dívida acumulada, com Juros. Cada novo deploy de microsserviço quebra seu sistema. E claro, você não adicionou monitoramento, não adicionou testes integrados. Então toda vez que você sobe algo, outra coisa quebra de forma inesperada.

Ainda está curtindo a Lamborghini antecipada?

O Mítico Homem-Mês

Philip Calçado escreve ótimos posts e apresentações sobre microsserviços do jeito certo. Se você leva esse assunto a sério, recomendo fortemente que leia seus textos, como o “Prerequisites” ou sua apresentação “Economics”.

Ele cita corretamente O Mítico Homem-Mês, de Fred Brooks. Insisto que os desenvolvedores leiam esse livro pequeno. É impressionante como a indústria inteira ainda repete exatamente os mesmos erros que Brooks relatou em seu livro, de projetos dos anos 60!

Para mim, microsserviços são um subproduto de empresas de tecnologia com programadores em excesso. Quando você ultrapassa a barreira de 5 desenvolvedores, um sistema “monolítico” com organização ruim e poucos testes automatizados pode ficar difícil de lidar. A consequência natural é a vontade de fragmentar. Você cria 2 equipes e 2 microsserviços e tenta coordenar. As equipes começam a se isolar e a praticar o jogo de culpar o outro quando novos bugs aparecem (“é culpa do microsserviço da outra equipe”).

É a Lei de Conway aplicada da forma errada:

Qualquer organização que projeta um sistema (definido de forma ampla) produzirá um design cuja estrutura é uma cópia da estrutura de comunicação da organização.

Também entra em jogo outro capítulo do livro do Brooks: o Efeito do Segundo Sistema. Todo desenvolvedor e toda startup precisa assumir que a primeira versão de qualquer coisa não é o melhor design. E o segundo sistema (a primeira grande reescrita) é o sistema mais perigoso que você vai construir. Como Brooks descreve:

O primeiro trabalho de um arquiteto tende a ser enxuto e limpo. Ele sabe que não sabe o que está fazendo, então procede com cuidado e grande contenção.

Enquanto projeta o primeiro trabalho, adornos e embelezamentos vão ocorrendo a ele. Esses ficam guardados para serem usados “na próxima vez.” Cedo ou tarde o primeiro sistema está pronto, e o arquiteto, com confiança firme e maestria demonstrada nessa classe de sistemas, está pronto para construir o segundo.

Esse segundo é o sistema mais perigoso que um homem já projeta. Quando faz o terceiro e os posteriores, suas experiências anteriores se confirmarão mutuamente quanto às características gerais de tais sistemas, e as diferenças identificarão as partes de sua experiência que são particulares e não generalizáveis.

A tendência geral é super-projetar o segundo sistema, usando todas as ideias e adornos que foram cautelosamente deixados de lado no primeiro. O resultado, como diz Ovídio, é uma “grande pilha.”

O que acontece depois? O CEO, o conselho, os investidores, seja lá quem for, começam a fazer a coisa errada: contratar mais e mais pessoas. Tomar mais e mais empréstimos. Em vez de pagar as dívidas, acumulam mais dívida. Caíram na armadilha que Brooks relatou no primeiro capítulo e que dá nome ao livro: O Mítico Homem-Mês.

Adicionar mão de obra a um projeto de software atrasado o atrasa ainda mais.

Projetos de programação complexos não podem ser perfeitamente particionados em tarefas discretas que possam ser executadas sem comunicação entre os trabalhadores e sem estabelecer um conjunto de inter-relações complexas entre as tarefas e os trabalhadores que as executam.

Portanto, alocar mais programadores a um projeto que está atrasado o atrasará ainda mais. Isso porque o tempo necessário para os novos programadores aprenderem sobre o projeto e a sobrecarga de comunicação aumentada consumirão uma quantidade cada vez maior do tempo disponível no calendário.

De novo: ignorando a variável “Tempo”. E confundindo “dívida” com “investimento”.

Antes de tudo, faça um favor a si mesmo e leia o maldito livro, duas vezes.

Faça Agile do jeito certo! E não, não é Kanban!

Se há uma coisa boa que todo o barulho do Lean produziu, é a noção de “Produto Mínimo Viável” ou MVP. Alguns chamam de “protótipo”. Outros chamam de “lançar em Beta” ou simplesmente “versão 1.0”. Não importa o nome. É o reconhecimento de que você não sabe muita coisa no início, então fazer engenharia excessiva na primeira versão é desperdício de tempo. Lean é sobre controlar o “desperdício”: fazemos o mínimo que funciona, medimos os resultados e evoluímos a partir daí.

Os cínicos vão dizer que qualquer protótipo que chega a produção nunca morre. E não estão errados.

O equilíbrio está em não fazer a versão “rápida e suja”. É pra isso que existem as técnicas ágeis. Faça o mínimo, organize o mínimo. É pra isso que existem os padrões de design orientado a objetos, do GoF ao DDD. Você não precisa aplicar TODOS os padrões, e é justamente isso que significa “super-engenharia”. Mas dá pra fazer o monolito mínimo que vai te permitir evoluir depois.

As pessoas criticam Ruby on Rails por não ser organizado “o suficiente”. Nick Sutterer, o criador do Trailblazer, tem um ponto válido.

Rails feito errado é ruim. Mas a conclusão NÃO deveria ser: “vamos fazer microsserviços”. Esse salto de fé é idiota e não faz sentido por todos os motivos que citei acima.

“Vamos fazer Agile de verdade e orientação a objetos de verdade” deveria ser a resposta inicial.

E por “Agile”, esqueça os post-its idiotas, esqueça as equações de estimativa baseadas em numerologia (isso dá um post inteiro por si só, porque story points e velocity são úteis, mas adicionar Montecarlo e outras coisas baseadas em distribuição Gaussiana não faz sentido). As únicas coisas “Ágeis” com as quais você deveria se preocupar são as técnicas de Extreme Programming (XP), incluindo os timeboxes baseados em iterações.

Você PRECISA fazer timeboxes. Pare, reavalie, mude de direção, e então continue. O modelo de “Pull” só faz sentido quando sua direção é muito, muito clara, escrita em pedra e imutável, como numa linha de produção de fábrica. (Que é exatamente onde o conceito de Pull, e o Lean, nasceram!)

Iterações, como testes automatizados, são como um Seguro. Você nunca consegue evitar todo o desperdício, mas pode minimizá-lo. Você pode se dar ao luxo de jogar fora o trabalho de uma Iteração inteira. Depois da iteração você mede os resultados e descarta se necessário, mudando de direção no processo. Jogar fora o que não serve é tão importante quanto adicionar coisas novas. Se você só acumula, está com um transtorno de acumulação!

Na dúvida, faça XP. Sim, parece mais “difícil”, e o Kanban é “mais simples” de explicar. Mas isso é motivo suficiente?

Esqueça Performance Bruta quando você NÃO precisa dela!

Outro problema é escolher linguagens ou frameworks por causa de performance.

Se você está no negócio de desenvolvimento web, isso é um DESPERDÍCIO enorme.

Entenda essa verdade: seus servidores vão ficar OCIOSOS na maior parte do tempo. E se você acha que seu web app está lento, a lentidão vem da PROGRAMAÇÃO RUIM que você fez, não da linguagem. Nenhuma linguagem boa vai salvar um programador ruim. Sempre digo que se performance fosse assim tão importante, todo mundo deveria estar usando C.

A maior parte do que você serve em apps baseados em HTTP, seja conteúdo para o usuário, seja resultado de API GET, pode ser CACHEADA! Se você não está usando uma CDN, está fazendo errado.

Sim, sim, sim, você acha que está construindo o próximo Spotify. Não está, pelo menos 99% de vocês não estão. E os 1% que fazem engenharia personalizada, com técnicas e stack próprios, e com sucesso: vocês são os 1%. Na verdade, são uma fração dos 1%. Não assuma que o que você faz é bom para o resto da população.

90% do que a maioria das pequenas empresas e desenvolvedores web solo precisam é só uma conta no Shopify e uma instalação padrão do WordPress. É isso.

Você está fazendo desenvolvimento de infraestrutura, como construir componentes customizados para Docker, Kubernetes, Terraform? Ferramentas de linha de comando? Daemons? Então escolha GO.

Está fazendo bibliotecas embutidas? Talvez a próxima geração do OpenSSL? Drivers? Então escolha RUST.

Está fazendo desenvolvimento mobile? Não tem muita escolha: Swift para iOS, Kotlin/Java para Android. Ou React Native para apps mais simples.

Está realmente construindo o próximo Whatsapp? O próximo Waze? O próximo Snap? Tem centenas ou milhares de usuários precisando de conexões de longa duração em redes não confiáveis fazendo broadcast de mensagens? Ou está construindo a próxima evolução de bancos de dados NoSQL distribuídos? Ou qualquer coisa que tenha o sentido real de “Distribuído” em sua definição? Então escolha ELIXIR.

Está fazendo uma aplicação web baseada em CRUD? Vai de RAILS e não olha pra trás.

Está fazendo tudo isso ao mesmo tempo? Use todas as alternativas então. E espero que tenha orçamento, porque vai precisar de uma equipe grande.

Conclusão

A Economia só faz sentido quando você considera o dia 1. Não esqueça a variável “Tempo”. Ela faz toda a diferença.

Você sempre vai ter Dívidas a pagar. Então seja inteligente na escolha de qual tipo de dívida você assume. Porque vai ter que pagar de volta eventualmente.

De novo: leia Brooks. Ele disse isso décadas atrás: NÃO EXISTE BALA DE PRATA. Não se iluda. Uma nova linguagem, um novo framework, uma nova arquitetura. Nada disso vai te salvar.

Em qualquer empreitada tecnológica, código não é a única preocupação. Diria até que numa startup de tecnologia, código é apenas 20% do problema. Uma startup de tecnologia é só uma empresa, como qualquer outra. Se você é o fundador ou CEO, tem que lidar com os 80% restantes: marketing, contabilidade, recursos humanos, questões legais, etc. Já é difícil o suficiente sem que sua equipe técnica te traga uma Dívida Técnica indesejada, a Lamborghini desnecessária, que você não vai conseguir pagar.

Você pode começar humilde no dia 1. Continue evoluindo, continuamente. Esse é o núcleo de qualquer processo Agile ou Lean: KAIZEN. Escolha dívidas inteligentes, pague-as aos poucos, continuamente. É o mesmo raciocínio de fazer um empréstimo no banco.

O dia 7.200 da Netflix NÃO é o seu dia 1.

O dia 4.800 do Facebook NÃO é o seu dia 1.

O dia 6.809 do Google NÃO é o seu dia 1.

Seja humilde. Entregue rápido. Pague suas Dívidas. Continue evoluindo continuamente. Pare de acreditar em contos de fadas e balas de prata.

A comunidade do Blender é tão apaixonada e comprometida que frequentemente produz curtas-metragens de alta qualidade, com nível quase hollywoodiano, usando o próprio Blender. A ideia é justamente estressar a ferramenta e identificar gargalos e problemas de usabilidade num fluxo de trabalho real.

Este post é, principalmente, para o “eu do futuro” poder voltar a uma lista de recursos centralizada. Como modelagem 3D não é meu trabalho em tempo integral, vou ter longos intervalos entre as sessões com o Blender. E eu sei que vou me arrepender se não descarregar o que aprendi num post enquanto ainda está fresco :-)

Primeiros Passos para Iniciantes

Antes de mais nada: se você está neste blog, provavelmente é programador. E deixa eu te dizer que o pessoal de gráficos tem uma visão de “usabilidade” bem diferente da nossa. A quantidade absurda de customizações, opções, atalhos e combinações rivaliza até com usuários de Vim e Emacs.

Ah, e a propósito: você vai precisar de um mouse com 3 botões de verdade. Touchpad não serve pra nada no Blender, e o mouse do Mac é horrível. Qualquer mouse barato de PC resolve.

Por padrão, o botão principal é o da direita, não o da esquerda como estamos acostumados. Mude isso nas preferências do usuário para selecionar com o botão esquerdo, e aí as coisas começam a fazer sentido. Enquanto estiver lá, habilite também a emulação do Numpad.

Aliás, vale muito a pena ter um teclado com numpad ou até um numpad separado. Você pode usar a fileira de números do teclado normal, mas o Blender foi projetado presumindo tanto um mouse de 3 botões invertido quanto um numpad.

Se você nunca estudou Blender antes, não vai conseguir descobrir nada explorando a interface por conta própria. A UI é inútil até alguém te ensinar o básico. Há centenas de termos que você simplesmente não vai entender, como Meshes, Edges, Seams, Nodes, Viewport, Subsurface, Modifiers, etc.

A coisa mais importante que você PRECISA fazer antes de continuar é assistir essa série completa de 9 partes do Blender Guru, chamada Blender Beginner Tutorial Series. Opcionalmente, você pode fazer depois, com calma, os Intermediate Blender Tutorials.

A série para iniciantes vai te ensinar o suficiente para você finalmente começar a se sentir confortável com a interface e as ferramentas. E não esqueça de imprimir e pendurar esse “cheat sheet” tão útil. Você não vai acreditar como a vida fica mais fácil quando incorpora os atalhos de teclado mais importantes.

Configurações Padrão Melhores

Por razões históricas, algumas configurações padrão não são as ideais. O conhecimento na área de renderização 3D evolui muito rápido.

A primeira coisa a fazer: trocar o motor de renderização padrão de Blender Render para o Cycles Raytracing Engine.

Depois, tratamento de cor. O sRGB EOTF padrão é basicamente errado. Você precisa baixar a configuração filmic-blender do Sobotka. No Arch Linux, basta fazer:

pacaur -S filmic-blender-git

Criei um script em ~/bin/filmic-blender com o seguinte:

env OCIO=/usr/share/blender/2.78/datafiles/filmic-blender/config.ocio blender

E sempre inicializo o Blender pelo terminal assim:

optirun ~/bin/filmic-blender

Isso faz duas coisas: primeiro, pré-configura o OpenColorIO para usar o substituto Filmic. Segundo, habilita a GPU externa do meu notebook para uso no Blender. Leia meu post “Enabling Optimus NVIDIA GPU on the Dell XPS 15 with Linux, even on Battery” para mais detalhes. No Windows ou Mac isso não é necessário, mas você ainda vai precisar carregar a configuração filmic.

Na aba Scene, você deve reconfigurar o “Color Management” assim:

Em seguida, configure o Cycles. Se você está no Linux com o Optimus instalado corretamente como expliquei antes, a opção CUDA deve aparecer nas preferências do usuário:

Na aba Render, você deve ter algo assim:

Na seção Dimensions, você vai ver que está configurado para Full HD (1920x1080 px) mas com apenas 50% (ou seja, vai renderizar metade do tamanho). Aumente para 100%. Se quiser um shot em 4K, ajuste as dimensões para 3840x2160 px. O 4K torna a renderização 4 vezes mais lenta que o 1080p, obviamente.

Na seção Performance há 2 campos para “Tile size”. O Blender vai dividir sua imagem em tiles, e cada tile renderiza em paralelo num core de CPU ou GPU disponível. Meu notebook tem 8 cores de CPU, então 64 é um bom tamanho, porque vai renderizar 8 tiles de 64 pixels cada em paralelo.

Quanto menos cores você tiver, maior deve ser o tile. Para minha GPU NVIDIA, só tenho 2 cores disponíveis (e não muita memória de vídeo!), então vale aumentar os dois campos para 512. Na GPU ela só renderiza 2 tiles por vez, e tiles maiores otimizam a renderização.

Como você provavelmente já adivinhou, o Blender Guru tem um tutorial muito útil: “18 ways to speed up Cycles Rendering”.

Isso cobre o básico das configurações padrão.

Você Precisa Pensar como Fotógrafo!

Você vai querer assistir MUITOS tutoriais online, porque realmente não é óbvio como usar melhor as ferramentas. Outro canal que gosto bastante é o BornCG e o CG Masters. Pegue alguns vídeos deles para ter uma visão mais aprofundada de ferramentas específicas, técnicas de modelagem e por aí vai.

E de verdade: você precisa praticar o máximo possível enquanto estuda. Uma área importante é a Fotografia. Isso é o que você vê quando seleciona a aba Camera:

Tem muita customização disponível aqui. Por exemplo: Focal length: 35.00, que é o que os fotógrafos conhecem como lente de 35mm, uma boa escolha padrão. Você pode usar grande angular de 200mm ou 300mm também, e shots internos, em salas pequenas, podem usar 24mm ou até 18mm. O artigo “Understanding Color Lenses” cobre o básico.

Depois, você precisa entender “Profundidade de Campo” (Depth of Field). Isso pode ser feito nessa configuração antes de renderizar, ou simulado após a renderização (se você escolheu separar o render em camadas), no Compositor.

Falando nisso, outra forma de controlar a Profundidade de Campo é reconfigurar o “f-stop”, que é a medida de exposição, ou abertura. O padrão é “128.0”, ou seja, “f/128”. Como referência, a câmera do iPhone 7s tem abertura f/2.2. Novamente, vale estudar mais sobre isso começando pelo artigo “What’s the Best F-Stop?”

Tirar uma foto (ou renderizar um still, no nosso caso) é muito mais do que simplesmente apontar e clicar. Você também precisa se preocupar com técnicas adequadas de composição, como a Regra dos Terços, a proporção áurea, e por aí vai. Você pode configurar isso no combo box “Composition Guides” mostrado acima.

Vale muito a pena se aprofundar no campo da Fotografia para melhorar o resultado final dos renders. Sou um amador e é muito empolgante conseguir aplicar técnicas do mundo real na renderização 3D.

Design de Materiais e Physically-Based Render (PBR)

O padrão ouro em modelagem e renderização 3D é certamente o Disney/Pixar RenderMan. Todos os filmes premiados da Pixar foram feitos com ele.

Mas o Blender aprende rápido. Todo paper da Pixar eventualmente vira parte do próprio Blender. O design de materiais, por exemplo, sempre foi bastante trabalhoso na ferramenta. Fiz alguns dos tutoriais eu mesmo, e criar materiais com as características corretas do mundo real, como Fresnel adequado e a distinção certa entre dielétrico e metálico, era um desafio.

Se você assinou o canal do Blender Guru, assista os tutoriais “How to Make Photorealistic PBR Materials - Part 1” e “Part 2”. E você vai acabar com essa configuração complicada de Nodes para materiais PBR:

E o Blender Guru acabou de postar um novo vídeo apresentando um recurso do próximo Blender 2.79 (ainda no 2.78 na época): a implementação do paper “Physically-Based Shader at Disney” como um novo shader nativo e otimizado chamado “Principled Shader”. É literalmente o Shader Definitivo, porque torna a criação e personalização de materiais realistas muito mais fácil, além de ser compatível com Renderman e Substance.

Conclusão

Ainda sou iniciante no Blender, tem uma estrada muito longa pela frente. Mas é um ambiente muito empolgante e estou aprendendo coisas novas e úteis o tempo todo. Todo mundo deveria experimentar!

Com o tempo, espero encontrar espaço para integrar o fluxo de trabalho do Blender com outras ferramentas como Unreal Engine ou Unity3D para criar coisas interativas também.

Esse post não é de forma alguma um tutorial completo ou referência definitiva. A ideia foi destacar algumas coisas que não são imediatamente óbvias quando você começa com o Blender e que podem te dar uma noção mais ampla do que ele é capaz de fazer.

Se quiser se aprofundar de verdade nas configurações, assista esse vídeo de setup do CG Master:

Sou um antigo proponente em matar deuses, é praticamente um hobby. Eles dão excelentes personagens de ficção em histórias para dormir, mas obviamente não existem. Como o bicho-papão ou papai-noel ou o coelhinho da Páscoa. E não, este não é mais um artigo focado em anti-religião, calma.

Pelas mesmas razões, eu quero desmantelar o mito do “Talento” e trazer os semi-deuses de volta à humanidade.

Talento é Altamente Supervalorizado

Eu realmente detesto o uso da palavra “Talento”. Ele deveria ser usado como um elogio, uma qualidade, mas é muito usado como uma desculpa. A raiz em latim da palavra significa simplesmente uma grande quantidade de dinheiro. O uso errôneo e comum de hoje em dia desvaloriza os reais esforços das pessoas realmente “talentosas”.

Toda vez ele é usado para denotar algo do tipo “eu nunca vou ser um Einstein, nem vou me incomodar em tentar”. É a desculpa preferida das pessoas preguiçosas.

Embora fatores ambientais e circunstanciais tenham um papel crucial, não existe ABSOLUTAMENTE NADA no nosso material biológico, como um gene, que impeça alguém de atingir níveis similares de sucesso dadas as mesmas circunstâncias.

Sim, algumas pessoas acabam, aleatoriamente, por estar no lugar certo na hora certa. É como se ganha uma loteria. E infelizmente, é impossível recriar a mesma rede de circunstâncias para todo mundo e replicar níveis de sucesso (mais sobre isso no fim do artigo).

Ao mesmo tempo não ajuda em nada acreditar no misticismo de que “talento” pode ser definido fisicamente, “geneticamente”. Esse é o pensamento que cria Josef Mengeles e muito do racismo e outras formas de segregação. Não existe predestinação.

Hoje em dia vocês já devem ter ouvido falar do conceito das 10 mil horas de treinamento deliberado para se tornar mestre em alguma coisa, primeiramente apresentado no livro “Outliers”, do prolixo Malcolm Gladwell.

De Bill Gates a Oppenheimer aos Beatles, o livro tenta descrever como o esforço continuado e focado dessas pessoas, as tais 10 mil horas (aproximadamente 5 anos em tempo integral), ajuda a explicar seus níveis de sucesso.

Geoff Colvin, em seu livro “Talento é Supervalorizado: O que realmente separa os empreendedores de classe mundial de todo mundo” tenta ir além de Gladwell e explica que, obviamente, só 10 mil horas de treino não bastam se não forem de “prática deliberada”: um treino obsessivo focado em melhoria contínua, acima da simples repetição da mesma rotina.

Em resumo: quer ter a chance de se tornar mestre em alguma coisa? Tenha a obsessão de treinar focado em melhorar milímetros e milissegundos ao longo de 10 mil horas. Repetir a mesma rotina, sem foco em melhorar resultados, não leva ninguém a lugar nenhum. É só passatempo.

Esse tipo de treinamento deliberado que Gladwell e Colvin detalham em seus livros, é um possível fator de sucesso.

10% do Cérebro: o Mito

Este é fácil de derrubar, então já vou começar por aqui.

Um dos aspectos “místicos” do talento está ligado à crença de pessoas que conseguem ativar mais de 10% do cérebro. O mito de que não usamos todo o nosso “potencial”.

Filmes de ficção recentes como “Lucy”, de Luc Besson, não ajudam em nada porque perpetuam essa crença popular. Vamos descrever desta forma:

“O cérebro humano constitui 1/40 do total da massa do corpo humano, em média, mas consome 1/5 de todas as calorias que absorvemos. De um ponto de vista evolucionário, onde cada órgão do nosso corpo foi criado e naturalmente selecionado por eras por eficiência, ter um cérebro que suga 20% de toda nossa reserva de energia diária por meros 10% de eficiência simplesmente não tem sentido nenhum.”

Pense em você mesmo neste instante. Você está usando seus músculos para ficar sentado agora? Usando suas mãos para scrollar o mouse do seu computador (ou dedo na tela do seu celular)? Talvez comendo ou tomando alguma coisa? Ouvindo alguma música? Respirando? Pode ficar tranquilo, você está usando mais de 10% do seu cérebro neste instante - Nature

Tirando esse fator do caminho, vamos continuar.

Humanizando Einstein

No geral, eu não respeito biografias. Raramente perco meu tempo lendo algum. Não sou contra, mas para mim biografia é uma história contada por um escritor, que levou em consideração todas as técnicas para me prender à história que ele quer contar. Toda biografia é limitada aos interesses do escritor, não do personagem que carrega o título do livro.

Na verdade, eu considero biografias como qualquer outro tipo de história de entretenimento. Exatamente na mesma categoria que assistir Capitão América ou Super Homem. Porque é exatamente assim que os escritores e diretores produzem os filmes de “baseado em fatos reais”.

Aliás, palmas aos irmãos Coen pelo filme “Fargo” que inicia com a frase “isto é uma história real”. E muitas pessoas até hoje, acreditam que é real. Uma trolada em todo filme que começa com o famigerado “baseado numa história real” e todos acham que estão assistindo fatos, e não entretenimento.

Coloque um nome que existiu, uma situação que existiu, e todo mundo associa a ficção inteira como se fosse real. Espero que ninguém pense que Lincoln tenha sido caçador de vampiros por causa do filme “Abraham Lincoln: Vampire Hunter”.

Mas se eu perguntar a qualquer pessoa do mundo, quem foi o maior super gênio cientista de todos os tempos, com as teorias que mais revolucionaram a humanidade, ninguém vai hesitar em dizer: Albert Einstein!

Mas por quê?

O físico Roger Schlafly, em seu livro “How Einstein Ruined Physics: Motion, Symmetry, and Revolution in Science” traz uma tonelada de evidências ao contrário.

Em resumo, sim Einstein realmente publicou muitas coisas muito interessantes, mas o super inflado mito criado ao redor de sua figura é muito mais danoso do que proveitoso para o futuro da física e seus sucessores. E continua a incentivar o mercado criador de mitos.

Einstein foi uma pessoa cheia de falhas, como todos nós. Bem longe de um semi-deus.

Mark Green, em seu artigo “New Book Says Einstein Highly-Overrated and Ruined Physics” descreve:

“O que torna Einstein tão grande? A história oficial começa assim: Albert Einstein, um jovem funcionário num escritório de patentes suíço, sozinho transformou a física de uma ciência estática e tridimensional em um universo espaço-temporal quadri-dimensional de explodir as cabeças e ’experimentos de pensamento’ solitários envolvendo gravidade, movimento, espaço e tempo. Einstein também fez progressos sem precedentes em entender a natureza da luz e energia e foi o primeiro a compreender a equivalência de energia e massa. As descobertas de Einstein não só transformaram a física moderna mas a forma como vemos o universo”

É o que todos nós sabemos. E eu fortemente recomendo que leiam o artigo completo de Mark Green, mas vamos aos pontos que interessam.

E=MC2: não foi inventado por Einstein!

A equação foi publicada 2 anos antes por Olinto de Pretto. Como Schlafly diz em seu livro “o entendimento da relatividade especial por Einstein … era inferior à de (Henri) Poincaré”. Aliás, se nunca ouviu falar do físico francês Poincaré, recomendo ler o livro “Chaos: Making a New Science” de James Gleick.

A noção de movimento e tempo como uma 4a dimensão separada do espaço tridimensional.

H.G. Wells especulou o conceito na famosa peça de ficção “The Time Machine” em 1894. Nesse mesmo ano Lorentz escreveu o paper científico onde ele “propõe o conceito de tempo local em um objeto móvel”. Poincaré escreveu em 1898 e outro em 1900 explorando o relacionamento entre movimento e tempo.

E a relação do E=MC2 e a bomba atômica?

Como Schlafly descreve, E=MC2 não é sequer necessário para a bomba atômica. A equação não dá nenhuma pista em como separar o átomo, ou como criar uma reação nuclear em cadeia, ou qualquer dos outros passos necessários em fazer a bomba atômica. Relatividade sequer é necessária para entender a liberação de energia de uma bomba de urânio ou plutônio, já que a liberação pode ser explicada por considerações de eletromagnetismo … previsões sobre a massa relativística estavam sendo testadas (pelo físico alemão Walter Kaufmann) em 1901, antes de Einstein escrever qualquer coisa a respeito.

E, pra completar, também foi H.G. Wells que publicou primeiro sobre o conceito de “bombas atômicas”.

Existiram muitos cientistas excepcionais, que trabalharam duro, antes e durante a era de Einstein. O matemático e físico francês Henri Poincaré, que o filósofo britânico Bertrand Russell (lembram da chaleira de Russell?) chamou de o maior homem que a França já produziu. O físico holandês e nobel Hendrik Lorentz. E o físico e matemático escocês James Clerk Maxwell.

De acordo com Schlafly, Maxwell foi quem primeiro cunhou o termo “relatividade” e criou a primeira verdadeira teoria da relatividade de massa e energia. O Eletromagnetismo gerou as mais importantes equações na história da ciência.

O subsequente trabalho de Poincaré em relatividade providenciou os teoremas que eram “matematicamente idênticos aos de Einstein” e a maioria do seu trabalho veio antes de Einstein. Lorentz e Poincaré tinham todos os principais aspectos da teoria da relatividade, e publicaram antes de Einstein.

Lembrem de outro detalhe da “história oficial”. Einstein trabalhava num escritório de patentes. Ele entendia sobre a importância da “propriedade intelectual” e teve acesso a muitos trabalhos antes de terem sido patenteados!

E assim nasce um talento, insubstituível e de valor inestimável … para o mercado de entretenimento de massas.

Atenham-se a outro detalhe: e se Einstein não tivesse existido? Teríamos sido privados da Teoria da Relatividade? Não, esse trabalho já estava praticamente completo antes dele. Outros teriam servido ao papel e a mídia e o folclore teriam apenas um nome diferente para chamar de Deus.

Talento, é relativo …

Todo gênio é, na verdade, um grupo!

Um fato importante é que a Teoria da Relatividade não foi uma invenção de uma pessoa. Um lobo solitário que teve um momento de “Eureka”. Momentos de Eureka são muito diferentes do que você imagina.

Entenda que hoje, Teoria da Relatividade é material básico de qualquer estudante de física. Nada notável.

Tudo que temos hoje é o resultado de centenas de indivíduos e grupos, que ao longo da história vieram usando o que se sabia antes, jogando fora o que não funciona mais, refinando o que funciona e adicionando novas peças para as gerações seguintes.

Nada do que fazemos hoje é verdadeiramente feito “do zero”. Tudo que temos à nossa disposição na atualidade, nos torna ordens de grandeza superiores, mais eficientes, mais rápidos, do que a geração que viveu 200 anos atrás, milênios atrás.

Não criamos nada baseados em verdades absolutas escritas em pedra milênios atrás. Evolução existe porque tudo é volátil. Tudo que vem se provando correto dado escrutínio de anos, séculos, se torna as ferramentas mais fortes para criar as coisas novas. Engenharia, Medicina, etc.

Graças a isso saímos da era da subsistência para a agricultura. Para a Revolução Industrial. Para a Era da Informação. E para onde estamos caminhando para a Era da Inteligência Artificial, e assim por diante.

“Talento” é uma forma de apontar momentos nessa história contínua e ininterrupta onde a sociedade como um todo vem subindo nos ombros de gigantes para dar passos mais largos ao futuro. Mas nenhum “um” indivíduo foi necessariamente pivotal. As conquistas seriam realizadas por alguém, mas de tempos em tempos, elegemos alguns indivíduos.

É mais fácil contar a história dessa forma. Só isso. Inovação é sempre um trabalho de grupo.

Serendipidade, Aleatoriedade e Sistemas Complexos

Infelizmente nós, seres humanos, somos péssimos em entender aleatoriedade. O mundo é altamente aleatório.

Mais do que Einstein, o cientista que publicou o trabalho mais significativo para a humanidade foi Charles Darwin e seu magnum-opus “On the Origin of Species” onde ele explica como complexidade emerge num mundo de eventos aleatórios através de seleção natural.

Eu escrevi em parte sobre isso no post “Processos, Metodologias e o Cérebro Humano” de 2013 e no post “Somos Matematicamente Ignorantes” de 2008. Vou tentar não me repetir muito.

A própria história de como sobrevivemos e evoluímos neste mundo, até chegar à forma humanoide que temos hoje, é o resultado do que tivemos que enfrentar no meio ambiente natural, ou não estaríamos aqui.

E um fator crucial no nosso cérebro primitivo é encontrar padrões, coisas que se repetem, e fazer isso muito rápido. Se, na calada da noite, no meio de uma floresta, virmos um pequeno par de círculos brilhantes se movimentando ao nosso redor e não associarmos aquilo na hora aos olhos de um lobo à espreita para fugir o quanto antes, não estaríamos aqui.

Esse mesmo mecanismo é que nos faz ver “rostos nas nuvens”, “imagens na borra de café”, “o rosto de cristo numa manta suja” e assim por diante. Identificar padrões em meio à aleatoriedade nos garantiu sobrevivência, mas no mundo moderno essa capacidade do nosso cérebro nos leva a conclusões totalmente erradas de causa e efeito.

Esse é o motivo pelo qual eu escrevi tanto sobre “correlação não ser a mesma coisa que causalidade”.

“cum hoc ergo propter hoc”

O mundo real é “complexo”, no sentido matemático, que descreve a exponencialidade de resultados dada uma rede de fatores. Não existe caminho linear, passo a passo, na biografia de ninguém. Nem mesmo em gêmeos que nasceram e viveram juntos, sob o mesmo conjunto de fatores, ao menos em teoria.

“Complexidade” não é o que estamos acostumados a imaginar que seja, e é o que nos impede de prever o tempo mais do que além do curto prazo. É o que leva à famosa borboleta de Lorenz, os fractais de Mandelbrot, e à Teoria do Caos. E mais recentemente à Teoria Moderna de Redes (incluindo Redes Sociais) publicada por autores como Barabási, Strogatz ou Duncan.

Quem me conhece sabe que faz uma década que sou fascinado por esse tema e já recomendei todos os livros desses autores. Foi inclusive o tema da minha primeira palestra pública em 2008, “Matando a Média”.

Além das tais 10 mil horas de treino deliberado obsessivo em direção à melhoria contínua, você ainda precisa estar exposto ao máximo de situações e pessoas possíveis para aumentar suas probabilidades de “serendipidade” que é a combinação do “estar no lugar certo, na hora certa e com a capacidade para agarrar a oportunidade”.

Isto é o que pode levar ao tal “sucesso”. Não há receita simples, apenas trabalho árduo e uma boa dose de aleatoriedade. Quando todos esses fatores se alinham, os resultados podem realmente parecer “milagrosos” ou “super-humanos”. E, dada uma boa quantidade de tempo e a mania humana de aumentar as histórias a cada vez que são repetidas, em poucos anos criamos novos Semi-Deuses.

Matando Deuses

Em toda mitologia existem muitos deuses. Tanto manifestações populares sobre crenças ao redor dos fatos “inexplicáveis” da natureza (na época) como tempestades, vulcões, as estações, o clima.

E também existem os semi-deuses, seres humanos que demonstraram algum tipo de superioridade ou feitos ditos “milagrosos” (na época) que nenhum outro humano jamais conseguiria atingir, com uma boa dose de criatividade ao contar a história.

Ambos os casos são explicáveis. Infelizmente a explicação lógica é bem menos dramática e não dá uma história tão boa assim, na maior parte das vezes. Curar doenças e avançar a humanidade não é tão “sexy” quanto um feito dito “milagroso”.

Porém nosso estilo de comunicação em massa na sociedade, jornais, revistas, televisão, filmes, redes sociais, adoram “história sexy”. Notícias negativas vendem. Sexy vende. Fatos lógicos não geram audiência. E, pior, alçam falsos mitos ao status de “verdade”.

“Diga uma mentira vezes suficiente e ela se torna verdade.” - Joseph Goebbels

Só porque você mesmo não sabe a explicação de alguma coisa, não se sustenta o argumento de que “portanto existe a possibilidade de algo místico”. Se eu não posso explicar que seu Deus não existe, tampouco você pode provar que ele existe. É uma argumentação falaciosa e não tem lugar numa discussão séria.

E isso sendo bonzinho, porque quem conta a história é quem carrega o ônus da prova. Não sou eu, que escuto, o obrigado a lhe desprovar.

Os últimos 200 anos foram fantásticos, porque viemos matando deuses em taxas nunca antes registradas na história da humanidade. É o reflexo de quanto avançamos em nosso conhecimento sobre a natureza e como ela funciona. Faltam poucos, não precisamos ficar criando mais.

Conclusão

As circunstâncias de por que certos indivíduos são alçados ao status de semi-deuses não têm uma resposta fácil. Muito menos uma sequência linear de eventos. Muito menos um filme de entretenimento, com altas doses de ficção e drama, que clama ser “baseado em fatos reais”.

Todos nós vivemos num mundo complexo, onde tudo se entrelaça numa rede infinita de possibilidades. Cada indivíduo tem circunstâncias muito diferentes.

Muitos não têm condição nenhuma e mesmo assim superam as expectativas, com determinação superior, com dedicação superior, com paciência superior, e alguns realmente chegam ao sucesso.

Talento “natural”?

Muitos têm as condições, mas não têm dedicação, não têm paciência, não têm determinação. E fracassam. Quantas histórias de herdeiros de grandes fortunas destroem o legado de seus antepassados?

Falta de Talento?

Todo mundo tem chances. Mas não adianta esperar, o melhor a se fazer é criar as capacidades o quanto antes para, se a aleatoriedade chegar e você estiver no lugar certo na hora certa, tenha as condições de agarrar a oportunidade e surfar nela.

Mas não há respostas simples, nem receitas, nem milagres, e nem talentos naturalmente nascidos com a genialidade pronta e, portanto, ideais inalcançáveis.

Agora, se você tem as condições e não recebe o sucesso no colo, não é o “azar” de ter nascido sem o gene do talento. É pura preguiça. Simples assim.

Não tenha ídolos. Tenha referências.

Essa é uma pergunta clássica e capciosa usada em entrevistas. E se você assistiu ao magnífico “O Lobo de Wall Street” do Scorsese, vai se lembrar dessa frase na hora.

Mas quantos de vocês pararam pra pensar de verdade no que essa pergunta implica?

Introdução

Existem inúmeras formas de tentar me vender uma caneta. Você pode falar sobre a tradição da marca fabricante. Pode exaltar a suavidade excepcional com que ela escreve. Pode tentar me convencer pela variedade de cores e tamanhos disponíveis. Pode até desviar o foco da caneta em si e começar a se gabar de quantas centenas de canetas já vendeu, o seu currículo de guerra.

Meu argumento é que você pode fazer tudo isso e ainda assim perder o ponto. E na maioria das vezes não vai vender a caneta.

Já vi isso acontecer muitas vezes. A maioria das palestras técnicas que assisti, por exemplo, segue esse roteiro:

1. Quem é o vendedor palestrante. Realizações. Currículo de guerra.
2. O que está sendo vendido. A Caneta.
3. Como a Caneta é boa ou como é fácil de usar.
4. “Compre.” Fim da história.

Não há nada de errado com esses pontos em si. Às vezes o palestrante vai além e faz coisas “chamativas” e “espetaculosas”. Uma sessão de live coding para demonstrar o quanto ele é bom (não a caneta). Uma demo técnica mostrando o que a caneta faz. Fogos de artifício e rojões. Mas tudo isso se dissipa rapidamente, e ninguém fala sobre aquilo depois. Não gruda.

E você não vende a caneta.

Às vezes a força bruta sozinha, o peso da marca por trás de você, é suficiente para persuadir muita gente. Mas não a maioria. Em vez de vender a caneta, o palestrante vende a big brand, Microsoft, Google, Facebook. Era “ninguém foi demitido por comprar IBM” nos anos 60. O famoso F.U.D. (a trifeta de “Medo, Incerteza, Dúvida”). Hoje é “ninguém, geralmente, é demitido por escolher Facebook ou Google”.

De novo, você não está vendendo a caneta.

Desenvolvimento

Como qualquer bom vendedor vai te dizer, você está perdendo o ponto mais importante da sequência acima, entre os itens 3 e 4. Você desperdiçou uma quantidade absurda de tempo descrevendo o “O Quê”. A maioria dos palestrantes técnicos passa um tempo enorme explicando o “Como”, com exemplos de código, live coding, tentando te convencer de como aquilo pode ser fácil.

Mas eles frequentemente esquecem de fazer a pergunta: “POR QUE essa caneta pode ser importante pra VOCÊ”. O “VOCÊ” sendo a audiência. Você não está conectando. Falta empatia. Você está apenas dizendo pra eles, em vez de persuadir. Dizer e persuadir são coisas completamente diferentes.

O POR QUE é o que mais importa. E a parte difícil com audiências grandes é que cada pessoa tem um “POR QUE” diferente que precisa de uma boa resposta.

Sempre que vejo um palestrante/escritor/evangelista dedicando tempo demais a coisas imateriais como “benchmarks”, “performance”, “arquiteturas hiper-modulares”, vejo alguém perdendo uma fatia enorme da audiência. Essas pessoas têm motivos legítimos para se preocupar com esses pontos, porque vivenciaram isso dentro de Unicórnios como Netflix, Facebook ou Twitter. Só que mais de 95% do público nunca vai ter esses problemas.

Portanto, você está tentando empurrar uma Lamborghini pra pessoas que não só não podem pagar por ela, mas que, mesmo que pudessem, ela não estaria nem perto do topo das prioridades. Sim, a Lamborghini é obviamente um carro rápido e bonito. Mas POR QUE eu preciso dela? POR QUE você está tentando me empurrar isso? POR QUE essa caneta sequer é relevante pra mim?

Sua prioridade não é a minha prioridade!

Vejo uma entrevista como uma palestra para uma audiência de uma pessoa. E vejo um post de blog como uma palestra para uma audiência que não consigo ver. A estrutura é exatamente a mesma.

Mas numa entrevista individual temos uma vantagem extra muito importante: você pode fazer perguntas diretas! Você percebe o quanto isso é valioso? Numa palestra com audiência você precisa fazer suposições sobre o que as pessoas querem ouvir. Numa entrevista você pode perguntar diretamente e dar respostas objetivas, eliminando o espaço das suposições.

A ironia é que a maioria das pessoas não faz perguntas em entrevistas. É muito mais fácil assumir: “todo mundo quer ouvir o que eu gosto de ouvir, porque eu entendo mais do assunto”. Isso é a falta de empatia no seu nível máximo.

Imagine que você é um engenheiro top trabalhando com tecnologia sensível a performance na sua startup unicórnio. Você tentou tudo e decidiu escrever componentes críticos de tempo real próximos ao metal, em C. E agora você dá palestras sobre como é fundamental que todo mundo comece tudo em C.

Comunicação é uma arte. Exige pesquisa, estudo, prática. Você precisa dominar muito bem sua língua nativa, a gramática, as muitas construções de frase que melhor transmitem a mensagem.

Existem vários “padrões de design” quando se trata de Teoria da Argumentação, muitas armadilhas bem conhecidas, falácias que você quer evitar. Tudo isso para criar uma linha de raciocínio sólida como rocha, simples de entender e difícil de refutar.

Você não quer ser facilmente derrubado. Então cada frase que você entrega é como um movimento de xadrez: você precisa antecipar 10 formas diferentes de ser refutado e ter respostas para cada uma.

Por isso você precisa praticar. Escreva, fale o máximo possível, independente do evento. O ponto é a oportunidade de se expor a um público com pouco risco, independente do tamanho da audiência ou do seu ego. Só enfrente uma audiência grande quando estiver confiante de que pode defender seus argumentos.

Calibre suas armas antes de usá-las. Quando você começa a tocar nos POR QUÊs, pode estar provocando feridas abertas na audiência, então é melhor estar preparado.

Mas se você não for atrás dos POR QUÊs, é muito pior: você se torna ESQUECÍVEL. Você recebe aplausos no final, e uma hora depois ninguém lembra seu nome. Qual é o propósito de um palestrante que ninguém lembra depois? Ou de um palestrante que é engraçado e as pessoas lembram das piadas, mas não lembram o conteúdo da palestra?

As pessoas simpatizam com o palestrante, mas a mensagem é irrelevante. Se você quer ser ator ou comediante, ótimo. Mas se você quer convencer pessoas de um ponto de vista, isso é fracasso.

O mesmo vale para a escrita. Você deveria ter aprendido isso na escola. Se você passou pela faculdade e teve que defender uma dissertação, DEVERIA SABER que ela PRECISA ser dividida em pelo menos 3 seções: Introdução, Desenvolvimento e Argumentação, e Conclusão. Essas são as partes do O QUÊ, COMO e POR QUÊ.

No mesmo tema, se você tem afinidade com técnicas Ágeis. Você se lembra da clássica estrutura de User Story? A maioria das pessoas acha isso super irritante. Toda ferramenta no estilo Kanban esquece disso: simplesmente te dizem “escreva aqui o que você quer”. E a maioria das pessoas só quer escrever o O QUÊ. Às vezes escrevem o COMO. Mas têm preguiça de pensar no POR QUÊ.

Como X, eu quero Y, para que Z.

A 3ª seção é elusiva, mas é a ÚNICA seção que importa. É o POR QUÊ. Por que VOCÊ quer AQUELA funcionalidade específica? O POR QUÊ é o critério de aceitação. O Critério de Conclusão. A única coisa que você deveria estar buscando. Escrevemos o que ACHAMOS que queremos, não o que realmente PRECISA ser feito. A estrutura de User Story é mais uma ferramenta para forçar o seu cérebro reptiliano a usar um pouco mais da sua matéria cinzenta mais moderna.

Conclusão

Meu objetivo é chamar atenção para um ponto que muitos palestrantes e blogueiros não estão fazendo: vocês estão se concentrando demais no O QUÊ e no COMO e deixando de explorar a verdadeira preocupação da audiência: o POR QUÊ!

De novo, sempre que você ver aquele tema barato de “minha linguagem é melhor que a sua” e o argumento é: “porque nos benchmarks podemos ver claramente que é 50% mais rápida” ou “podemos ver claramente que usa 50% menos memória” ou “podemos ver claramente que consegue rodar mais processos concorrentes ao mesmo tempo”. Todos esses pontos estão perdendo o alvo.

Isso é o COMO. Tudo bem.

Mas 95% da sua audiência raramente vai se identificar com esses pontos. Eles vão concordar num nível consciente, mas o subconsciente vai lhes dizer a verdade: “você não tem esse problema.” Na maioria das vezes os servidores deles estão ociosos, sem fazer nada. De que adianta um ganho de performance de 50% ou 200% pra eles? Não adianta nada.

É uma falta grave de empatia quando um programador, trabalhando numa empresa grande, com muitos times diferentes colidindo com monólitos enormes e código legado, decide que microsserviços é o caminho. E agora ele “sabe” que se é bom pra ele, deve ser bom pra todo mundo, certo? Portanto, qualquer um fazendo diferente é um idiota.

Não é. A maioria dos outros times no mundo pode ser de 3 a 5 pessoas com projetos que ainda nem chegaram à luz do dia. E aí está: tentando implementar sua super-arquitetura mirabolante, sem obter nenhum valor de volta, porque isso atrasa o tempo de lançamento no mercado.

Ah, a concorrência os alcançou, lançou primeiro, eles perderam o timing, e tudo porque confiaram na sua opinião de visão estreita, na sua falta de empatia com sua audiência. E isso no caso em que eles te ouviram. A maioria já esqueceu o que você disse, porque nunca tocou nas preocupações reais deles de qualquer forma.

E eu também sou culpado, faço isso às vezes. No começo da minha carreira fazia mais, e quanto mais velho fico, mais cuidadoso me torno com a forma como construo o que quero dizer. É muito difícil enxergar além das nossas pequenas rotinas. É difícil se comunicar com uma audiência maior e diversa. Mas se esse é o papel que escolhemos perseguir, precisamos fazer melhor.

Espero que isso tenha dado a vocês alguma perspectiva sobre como estruturar seu pitch em palestras pequenas ou grandes, entrevistas individuais ou posts de blog. É tudo a mesma coisa: O QUÊ, COMO, e por último mas não menos importante, o POR QUÊ!

“Mas o que é felicidade? É um momento antes de você precisar de mais felicidade.” - Don Draper

Um dos grandes mitos da sociedade moderna, perpetuado por uma torturante repetição diária nas redes sociais, é o falso “objetivo” da “busca pela felicidade”.

A esse mito se soma o mito da “motivação”. TL;DR: motivação é superestimada, muito mais do que realmente merece.

“As pessoas podem ter dois tipos de mentalidade, diz ela. Aqueles com ‘mentalidade fixa’ acreditam que seus talentos e habilidades estão cravados em pedra. Aqueles com ‘mentalidade de crescimento’ acreditam que seus talentos e habilidades podem ser desenvolvidos. Mentalidades fixas enxergam cada situação como um teste de seu merecimento. Mentalidades de crescimento enxergam as mesmas situações como oportunidades de melhorar.” - Daniel H. Pink, Drive: The Surprising Truth About What Motivates Us

Junto vem o mantra repetido do “faça o que ama”. Como discorri em 2014, essa ideia é uma forma mesquinha de desvalorizar o trabalho dos outros.

“…, o grande problema da narrativa do “ame o que você faz” é que ela está vinculada a um discurso de felicidade que é “estar no topo da montanha russa o tempo inteiro”. Como se uma vida normal, cotidiana, rotineira não pudesse ser uma vida de satisfação. Tudo isso torna esse cenário preocupante.” - Bárbara Castro - “5 Razões pelas quais o ‘faça o que você ama’ não é a solução”

No nosso pequeno grande mundo de tecnologia, isso leva muita gente a concluir: “vou trabalhar numa startup ou abrir a minha própria”. A decisão em si não tem nada de errado. O problema é chegar nela movido pelos mitos anteriores, o que vira uma fonte enorme de frustração desnecessária, como já expliquei em 2013.

“Não vou me equivocar: eu sou profundamente cético com esse sistema. Sou cético quanto à escravidão desse sistema, fetichização autocongratulatória de “disrupção” e ao mesmo tempo se tornando tão obviamente o tipo de instituição impassível que quer substituir. Sou cético quanto à visão de curto-prazo da comunidade de startup. E sou particularmente cético pelo seu desprezo quanto às vidas das pessoas que participam e a vida daqueles que vivem no mundo que as startups procuram reformular. Não vamos nem começar a discutir o conluio, cartelização e outras atividades de corrupção de mercado que são tão comuns no mundo dos VCs. O ponto sendo: é um jogo ruim, e um jogo de fraude.” - Alex Payne

Some a isso o “consenso” das redes sociais de que o mundo não para de piorar. Tudo hoje seria pior. As pessoas, piores. Os trabalhos, piores. O meio ambiente, destruído. Tudo ofende todo mundo o tempo todo, e ninguém consegue parar de julgar os outros.

Eu discordo, como já expliquei também em 2013 e repito todo ano: o mundo está melhor, em melhoria constante, e o futuro será ainda melhor. Aproveito para homenagear um dos homens que ajudaram a mudar minha perspectiva sobre o mundo, o recém-falecido Dr. Hans Rosling.

A Perpetuação dos Mitos

Não faltam livros, palestras, programas de TV, filmes e tudo mais construído ao redor da ideia de que todos “devem” ser felizes, o tempo todo. E que, se você não está feliz, está fazendo alguma coisa muito errada. A busca incessante pela “felicidade ideal” virou uma das obsessões mais insalubres e cruéis dos últimos dois séculos, ao lado do consumo excessivo de açúcar. Esse é outro assunto, embora açúcar e felicidade costumem andar correlacionados.

Existem 2 conceitos que todos precisam entender:

1. Você provavelmente não tem depressão. Hoje em dia todo mundo “está deprimido”, claro, porque “descobrir o que ama fazer” dá muito trabalho e traz muito “sofrimento”…

Não, você só está entediado, momentaneamente.

Dizer “estou com depressão” em vez de “estou entediado” ficou tão comum que a condição clínica de verdade precisou de outro nome para se diferenciar, o “Major Depressive Disorder”. Essa é uma condição médica séria demais para ser tratada com tanta falta de consideração.

2. Normalmente, mesmo depois de passar por eventos que consideramos muito ruins, ou muito bons, tendemos a voltar ao mesmo nível de “felicidade” (ou de tédio) em que estávamos antes deles. Isso se chama “Adaptação Hedônica”. É a principal razão de a “busca pela felicidade” ser uma jornada tão cruel: quem não entende esse mecanismo vive frustrado o tempo inteiro.

“Quando o suficiente não é o suficiente, nasce um hedonista.” - Sukant Ratnakar

Você já pensou em “Eu finalmente serei feliz quando me casar.” Ou “se eu conseguir esse trabalho, vou me sentir totalmente satisfeito.” Ou talvez você se relacione mais com o outro lado da moeda “Eu nunca vou ser feliz agora que recebi esse diagnóstico médico.” Ou “Eu não posso ser feliz enquanto tiver que pagar essas dívidas.” Pesquisas psicológicas revelaram duas descobertas importantes quando se fala nessas crenças: As coisas que achamos que nos tornarão felizes nunca nos tornam felizes pelo tempo que imaginamos. Ao mesmo tempo, eventos negativos na vida e desafios não têm um impacto duradouro na nossa felicidade como acreditamos que teriam também. - Sonja Lyubomirsky, Ph.D - The Myths of Happiness

“Nós parecemos obcecados por motivação, nos incitando rumo a algo além da vida disponível a nós agora, e tratamos essa motivação como se fosse uma parte importante da história da sabedoria, o que ela não é.” - Jennifer Hecht - The Happiness Myth: The Historical Antidote to What Isn’t Working Today

Por causa da Adaptação Hedônica, qualquer mudança parece fornecer uma “motivação” nova, a sensação de que “finalmente engatamos no caminho certo”. A menos que ela traga um propósito novo, é só mais do mesmo. Logo nos acostumamos ao “novo normal” e voltamos ao tédio.

Sem entender isso, você fica preso no ciclo interminável e insatisfatório da “grama do vizinho é sempre mais verde”. O efeito mais perverso desses mitos aparece quando a pessoa passa a culpar os outros pelos próprios problemas. “Eu não consigo porque meu marido…”, “Eu não consigo porque minha família…”, “Eu não consigo porque meus colegas de trabalho…”, “Eu não consigo porque meu chefe…”, “Eu não consigo porque a sociedade…”

Nesse momento você está perdido. Quer mudanças, mas quer que tudo ao seu redor mude, menos você mesmo. Essa é a melhor definição de covardia: viver de justificativas e desculpas superficiais para não se esforçar, para evitar a dor, para maximizar o prazer de curto prazo. É o comportamento de um viciado, e julgar tudo e todos é a droga.

Só você está destinado a coisas grandes, mas alguma coisa ou alguém te impede. Só você é especial. Só você merece tratamento diferenciado. Antigamente chamaríamos isso, educadamente, de “imaturidade” ou “criancice”. Hoje eu diria que a maioria se encaixa mesmo em “Transtorno de Personalidade Narcisista”.

“Transtorno de personalidade narcisista é um transtorno mental em que as pessoas têm uma sensação inflada de sua própria importância, uma profunda necessidade de admiração e uma falta de empatia. Mas por trás dessa máscara de ultraconfiança está uma frágil auto-estima que é vulnerável à menor crítica … (isso) causa problemas em muitas áreas da vida, tais como relações, trabalho, escola ou assuntos financeiros. Você pode ser infeliz no geral e frustrado quando não lhe é concedido favores especiais ou admiração que você acredita que merece. Outros podem não gostar de estar perto de você, e você pode achar que seus relacionamentos não te satisfazem.” - Mayo Clinic

No mundo moderno, eu reduziria isso à “Cultura do Like”. Triste.

Conclusão

Essa busca incessante pela “felicidade ideal”, esse “fazer somente o que você ama” e essa certeza de que “o mundo vai acabar” tornam as pessoas muito fracas. Baixa autoestima, baixa empatia, narcisismo altíssimo e uma sensação de “depressão” que chega a paralisar. No fim, a pessoa só atira para todos os lados, por falta de “propósito” e por frustração constante com tudo e com todos.

Felizmente, eu nunca tive esse problema. Conheci pessoas que têm, e este artigo é dedicado a elas, como um “wake up call”. Isso não quer dizer que eu não tenha tido momentos infelizes e crises pessoais. Já perdi muita coisa, financeira e pessoalmente. Negócios, amigos, relacionamentos. Não estou exagerando. Mas aceito meus prejuízos e pago por eles, como parte da vida: No Pain, No Gain.

Ambiente de trabalho “fancy” nunca foi preocupação. Já trabalhei embaixo de uma lona (!) quando pintaram o pequeno escritório onde eu era estagiário, no verão, sem ar-condicionado, porque iam dar uma festa e o trabalho não podia parar. Já trabalhei dentro de um armazém de logística, com teto de zinco, só com ventilador, caminhões entrando e saindo ao lado.

Dormi no chão do escritório dezenas de vezes. Carreguei móveis pelo meio da rua para mudar de sede. Varei muitas noites não pagas. Tomei esporro na cara por coisas que nem eram minha responsabilidade (eu era estagiário). Fiz um monte de coisas fora do meu trabalho de verdade, briguei com gerentes, com “colegas” e com fornecedor.

Nunca tratei nada disso como “fim do mundo”. Era só o inevitável. O famoso “aceita, que dói menos”.

Não é à toa que sou um Engenheiro. Engenheiro resolve problema, e a nossa obsessão é sempre encontrar um jeito mais eficiente de fazer a mesma coisa. Nenhum engenheiro resolveu nada só com mimimi.

Também não existe “trabalho que me desvaloriza”. Se eu precisar recortar um Photoshop, não vou tratar isso como trabalho braçal inútil. Não existe trabalho inútil. Existe má vontade. Toda tarefa corriqueira e subestimada, feita com a cabeça, pode levar a grandes descobertas acidentais.

“O inventor da Coca-Cola não era um homem de negócios astuto, um vendedor de doces, nem um sonhador buscando enriquecer no ramo de bebidas. John Pemberton só queria curar dores de cabeça. Farmacêutico de profissão, Pemberton usou dois ingredientes principais em sua esperada cura para dor de cabeça: folhas de coca e nozes de cola. Quando seu assistente de laboratório acidentalmente misturou os dois com água carbonada, o resultado foi a primeira Coca-Cola do mundo.” - 10 Awesome Accidental Discoveries

Muitos desses narcisistas, na aura de autoimportância, acham que precisam do ambiente perfeito, que alguém lhes dê as condições para realizar coisas grandiosas (a ênfase no “dê” é porque eles se recusam a conquistar sozinhos o que precisam). Isso é uma grande besteira. Ainda estou para ver alguém que pensa assim realizar qualquer coisa relevante para alguém.

Na minha experiência, todas as grandes descobertas nasceram em condições humildes, com pessoas que tinham interesse real no que faziam. Apenas isso. Profissionais, “craftsmen”, interessados em aperfeiçoar o próprio conhecimento e que, por consequência, chegaram a coisas grandes que beneficiaram mais gente. Você não planeja algo revolucionário. Ele acontece por acidente, dadas as condições ideais de temperatura e pressão daquele momento.

“A questão não é quem vai me permitir: é quem acha que pode me impedir.” - by Akita.

Eu não sou programador com o intuito de um dia superar Bill Gates ou Linus Torvalds. Dá para fazer coisa boa sem ser cegamente arrogante. 30 anos depois, ainda me divirto com coisas triviais: um código novo que compila, uma configuração que otimiza minha GPU, montar um Raspberry Pi, testar uma linguagem nova, ajustar meu editor de textos, pesquisar, aprender, evoluir, e assim vai. “Fazer o que ama” é fazer bem essas coisas pequenas. E “ser feliz” é um processo de tentativa e erro, sempre em movimento, que se conquista aos poucos em vez de num destino final.

Quem aproveita o presente, o que existe ao redor e ao alcance neste momento, em vez de perder tempo com o “e se no futuro…”, é quem tem mais chance de fazer o que os outros não conseguem, cegos pela jornada da felicidade impossível. Restrições levam à Inovação, como venho repetindo faz anos.

“carpe diem, quam minimum credula postero” - “Faça o melhor possível com o tempo (limitado) que você tem”.

“Quem vive de passado é museu. E quem sofre com o futuro longínquo é um doente mental.” - Desconhecido.

Coincidentemente, enquanto estava pesquisando para escrever este post, saiu o podcast do Hipsters Ponto Tech onde fiz uma pequena participação justamente para falar sobre o assunto de Carreiras em tecnologia.

E releiam meus antigos posts mencionados acima, relacionado a estes assuntos:

• O Mundo Hoje é Muito Bom! Feliz 2013!
• Carta para um Jovem Programador Considerando uma Startup
• Restrições são libertadoras: menos é mais
• NÃO Faça o que Você (“ACHA”) que Ama

TL;DR: Aprenda a aprender, e aproveite melhor sua vida.

Os profissionais “criativos” (como se “criativo” fosse restrito a pintores e ilustradores) sempre foram os seguidores mais fiéis da Apple, e com razão. A plataforma foi o berço de ferramentas essenciais como Photoshop, QuarkXPress, PostScript, PDF e QuickTime. A Apple estabeleceu os padrões da criação de mídia, e qualquer um que era alguém usava essas ferramentas.

A Microsoft focava no mercado corporativo, não nos criativos. O Linux ainda engatinhava, e a maioria dos desenvolvedores nem sabia a diferença entre CMYK e RGB. Ficavam satisfeitos em ter um bitmap tosco na tela.

Tenho uma teoria: achamos que dominávamos a tecnologia no final dos anos 90, que estávamos no topo do mundo. Essa euforia era fruto da Bolha da Internet, que estourou junto com o 11 de setembro. A depressão que se seguiu desperdiçou os próximos 3 a 4 anos enquanto todo mundo tentava descobrir o que fazer a seguir.

A Apple teve a sorte de escapar da explosão. Ela já estava no fundo do poço desde 1997. A reorganização do portfólio de hardware e o lançamento do iPod criaram uma bolhinha própria. Steve Jobs havia voltado e trouxe bons desenvolvedores que fizeram do OS X um prazer de usar, não só para criativos, mas também para desenvolvedores.

O processo antitruste contra a Microsoft em 2000, o estouro da Bolha da Internet em 2001, o lançamento do iPod em 2001, a transição do System 9 para o OS X/BSD em 1999, a troca do PowerPC para Intel em 2005, o lançamento do desejadíssimo Titanium PowerBook G4 em 2001. Tudo isso junto deu à Apple uma vantagem enorme. E enquanto todo mundo estava em baixa, a Apple parecia maior do que realmente era.

Aí vieram 2007 e 2008 com um novo impulso: o iPhone, a App Store e a necessidade de usar o Xcode, disponível apenas em computadores Apple. Diferente de ficar preso ao Windows por causa do Visual Studio, usar o Xcode era um motivo a mais para comprar um Mac.

As distros Linux ainda sofriam. Até então, estávamos presos ao maldito X11. Se o núcleo de um sistema Linux era moderno, o X11 em cima era o pior dos mundos. A Apple foi esperta o suficiente para não adotá-lo e criou o Quartz do zero, melhorando-o a cada nova versão do OS X. Levou cinco anos para estabilizar direito. Só agora, em 2017, estamos finalmente saindo do X para o Wayland/Weston.

A Microsoft também sofreu depois que Bill Gates passou as rédeas para Steve Ballmer. A trajetória do XP até o Windows 10 passou pelos desastres do Vista, do Windows 8 e do Windows Mobile, além das inúmeras tentativas de ressuscitar o Internet Explorer, o maior Walking Dead da história da tecnologia. A era Ballmer foi um desastre.

Aí veio o iPad. E Steve Jobs morreu.

A Apple está presa em 2010.

E nós também.

As grandes distros Linux, a Microsoft, os fabricantes de hardware para PC, as viradas de grandes empresas (Nokia, Blackberry, Motorola), o começo da era das GPUs, o fim das guerras de clock da Lei de Moore em direção à computação paralela, a ascensão do ARM. Levou dez anos para a poeira baixar, e foi preciso a Apple ficar parada por seis anos para que todos os outros conseguissem alcançá-la.

Ballmer passou o bastão para Satya Nadella. A Microsoft adquiriu a Xamarin, deu passos enormes em direção ao open source e até o Ubuntu passou a rodar nativamente no Windows 10.

E os asiáticos. Samsung, LG, Huawei, sul-coreanos e chineses forçaram os norte-americanos a se mexerem mais.

Um último legado da era Steve Jobs foi matar o Adobe Flash (finalmente!) e impulsionar as tecnologias HTML 5, comprimindo dez anos de evolução em cinco. Foi por causa do iPhone que a Web é o que é hoje.

O Google entrou em campo e assumiu o espaço deixado pelo Internet Explorer. O WebKit se tornou a referência obrigatória de navegadores. O JavaScript se transformou na nova plataforma de aplicações, impulsionado pelas redes sociais em constante evolução.

Para o bem ou para o mal, as redes sociais forçaram o surgimento de uma nova geração de aplicações web complexas e interativas. O Gmail e a Web 2.0 serviram de exemplo, e com o novo ambiente mobile, tudo convergiu para aplicações multiplataforma e ubíquas.

Hoje é mais fácil do que nunca trocar de sistema operacional no desktop, porque já treinamos o hábito de pular entre desktop e dispositivos móveis.

Por que ficou fácil migrar entre macOS, Windows ou distros Linux? Ou entre macOS e iOS, ou entre Linux e Android? Porque a maior parte do software está “na nuvem”. O Linux domina o mundo da nuvem que a Amazon estreou em 2006 com S3 e EC2, seguida de perto pelo Google Cloud, Microsoft Azure e outros competidores menores.

Porque em qualquer plataforma existe pelo menos um bom Chrome.

Porque os apps que usamos são majoritariamente web: Gmail, Spotify, Slack, Hangout, Twitter, Facebook, YouTube, Netflix, Amazon. E a outra metade está disponível nativamente no iOS ou Android: WhatsApp, Waze, Swarm, Snapchat, Instagram.

Dez anos atrás, com o lançamento do iPhone, a indústria de tecnologia finalmente começou a se organizar.

Foi um jogo de gato e rato até uns cinco anos atrás, quando as coisas começaram a se estabilizar.

Depois que Jobs morreu, ainda tínhamos a expectativa de que a Apple continuaria avançando, ainda que num ritmo mais lento sem o chicote do Jobs.

Não aconteceu. Foram decisão ruim atrás de decisão ruim, e a sensação é de que voltamos ao início dos anos 90, na era de Scully, Spindler ou Amelio.

Mas agora existem alternativas sólidas disponíveis: o Windows 10 Anniversary Edition é finalmente um Windows competente, recuperando a glória dos meados dos anos 90. E as grandes distros Linux são coesas, exigindo pouco ou nenhum ajuste nerd em arquivos de configuração obscuros, empurradas pela Canonical, para o bem ou para o mal.

E a maioria dos apps que usamos no dia a dia está disponível. Dá até para encontrar um bom editor de texto multiplataforma baseado na web na forma do Atom.

A Apple também deixou o legado da compilação multiplataforma ubíqua na forma do LLVM. Serviu às próprias necessidades deles de ter Objective-C disponível em PowerPC, Intel, ARM e nos processadores Apple Ax. Mas o LLVM é agora a melhor espinha dorsal para permitir que linguagens como Rust, RubyMotion e Crystal existam e criem binários rápidos em múltiplas plataformas.

“O conselho da Apple precisa ir embora.” “Tim Cook precisa renunciar.” Tenho certeza que muita gente grita isso por aí, mas não tem Steve Jobs esperando para voltar. A Apple é grande o suficiente para que a inércia sozinha a mantenha andando por mais alguns anos, mas ela corre o risco real de cair na irrelevância.

Outras indústrias como energia, saúde e genética evoluem do jeito delas, mas a tecnologia da computação está num perigoso marasmo.

As linguagens de programação pararam de evoluir em meados dos anos 90. Todas as linguagens “novas” são amálgamas de recursos que já existiam desde os anos 70 e 80. Os processadores estão presos em fazer transistores menores e mais eficientes em termos de energia. E já chegamos lá: computadores de US$ 9 são suficientes para tarefas triviais como navegar na web. A ponto de estarmos colocando processadores em tudo: inclusive numa escova de dentes bluetooth que registra suas sessões de escovação.

Viu os produtos da CES 2017? Travesseiros e camas que monitoram seu sono e sincronizam com um app. Máquinas de lavar. Aspiradores de pó. Dispositivos fitness. Dispositivos de saúde. Assistentes pessoais como a Alexa. Tudo captura dados seus e sincroniza na nuvem.

A nuvem também chegou ao pico. É ubíqua, acessível e barata. A tecnologia em geral está absurdamente barata hoje em dia.

Wearables e VR são boas novidades, mas mesmo que se tornem ubíquos, continuam sendo apenas uma extensão dos casos de uso que a revolução do iPhone iniciou.

Mobile, wearables, redes sociais, só deixaram as pessoas mais ansiosas. Dar “voz” a todo mundo online não melhorou as coisas, só aumentou a ansiedade geral. Opiniões estão em oferta tão grande que valem cada vez menos.

Cada pessoa online é agora uma fonte de terabytes de informação inútil para gerar pseudo-estatísticas que não servem para quase nada. Cada pessoa é agora definida por um monte de dados na nuvem.

Não faço ideia para onde vamos daqui. Como testemunha da história, tenho que dizer que sinto falta da empolgação de explorar novas fronteiras. Tivemos isso a partir dos meados dos anos 90. Demos uma pausa depois do estouro da Bolha da Internet, mas recuperamos com tudo em 2004. Perdemos depois de 2010.

2010 foi o ano mais longo que já vivi. Talvez estabilizar seja uma coisa boa. Quem sabe?