Essa foi a semana no X, e se você só lê manchete, é uma conclusão razoável. Este texto é pra quem quer saber o que cada uma dessas coisas faz de verdade.

Explodiu no dia 9, quando a conta abaixo resumiu o que um desenvolvedor de Atlanta, Brandon Thomas, vinha publicando desde o fim de setembro: sete clones de código aberto dos produtos principais da Adobe, escritos em Rust com ajuda do Claude Opus 5.5. Photoshop, Illustrator, Premiere, Lightroom, After Effects, InDesign, Acrobat. Tudo de graça, tudo feito em “sala limpa”, sem uma linha de código da Adobe. A conta que viralizou foi esta:

AI is now being used to recreate Adobe's software, a developer has released seven free, open-source apps as clean-room alternatives to Adobe's main tools:

- PhotoCraft → Photoshop
- VectorCraft → Illustrator
- FilmCraft → Premiere Pro
- LightCraft → Lightroom
- EffectCraft → After Effects
- DesignCraft → InDesign
- PrintCraft → Acrobat Pro

Built in Rust with help from Claude Opus 5.5, they run on Windows, Linux, and macOS under MIT/Apache licenses without using Adobe's source code.

— Pirat_Nation (@Pirat_Nation) October 9, 2026

Na mesma semana, o REA, “Reverse Engineer Anything”, passou de 100 mil estrelas no GitHub, ganhando dezenas de milhares por dia. A promessa da página: “viu uma feature num app que você quer no seu produto? Peça pro seu agente investigar com o REA e construir uma versão pro seu projeto”.

E quem acompanha retrogaming sabe que 2026 é o ano que não para de dar. Tem uma planilha comunitária tentando listar os ports não oficiais pra PC, com uns 100 jogos de Ship of Harkinian a Skate 3, e ela está sempre atrasada. O canal Video Game Esoterica publica port novo quase todo dia: Time Crisis decompilado do arcade, Daytona USA, Bloodborne.

A versão de Xbox One do Forza Horizon 2, presa lá desde 2014, roda em Windows. O AnyPS5 promete converter executável de PS5 em binário nativo de PC, e emuladores de PS5 como o KytyPS5 e o SharpEmu já rodam Astro Bot com gameplay de verdade. Boa parte disso com IA no meio, alguns abertamente vibe-coded.

Daí o consenso: programar, em geral, acabou. Todo binário é reversível e reutilizável, basta apontar o agente. Minha posição é que ficou muito mais fácil mesmo, que ainda está longe da bala de prata que as pessoas imaginam, e que o motor por trás disso, o LLM, parou de crescer exponencialmente. O resto do texto são os motivos.

TL;DR: engenharia reversa é uma disciplina de 40 anos com ferramenta madura, e a IA acelerou o trabalho braçal dela, com destaque pro retrô, onde o binário está disponível, é minúsculo e o alvo não se move. Os clones da Adobe são alpha com centenas de bugs abertos e print bonito. O REA é uma caixa de ferramentas que exige o binário na mão, Ghidra ou IDA instalados, e muito token. O que vale dinheiro hoje nem binário tem: é SaaS, nuvem, parceria com fabricante e décadas de ciência de cor. Reescrever o Bun, com o autor do projeto e 64 agentes, custou US$ 165 mil. Pule pra linha do tempo, pro REA, pros clones da Adobe, pro caso Bun, por que o retrô anda rápido ou pras respostas no final.

Antes de tudo: eu não gosto da Adobe

Pra ficar claro de onde eu falo. Eu detesto as práticas comerciais da Adobe tanto quanto qualquer um. Fui cliente pagante por anos, usei Photoshop e Premiere extensivamente, mais Lightroom e After Effects, e saí pelos mesmos motivos que todo mundo sai: assinatura compulsória, cancelamento com multa, preço subindo sem contrapartida.

E é exatamente por ter usado a fundo que eu sei o tamanho do que está dentro daquelas caixas. Quem acha que Photoshop é camada, crop e texto nunca precisou de prova de cor pra gráfica, nunca abriu um RAW de câmera cujo perfil de cor a Adobe mantém há vinte anos, nunca fez a conformação de material de cinema, o trabalho de reunir o material bruto da câmera pra finalização. Vou chegar lá, depois do básico.

Engenharia reversa não nasceu semana passada

Todo emulador que você já usou existe porque alguém abriu hardware, desmontou binário, farejou protocolo e, em alguns casos, quebrou criptografia. A disciplina tem jurisprudência, ferramenta comercial e uma história de décadas. Uma linha do tempo resumida, com os marcos que mais importam:

• 1982 a 1984: a Compaq reescreve a BIOS do IBM PC por engenharia reversa, e em 1984 a Phoenix vende uma BIOS licenciável feita em sala limpa, com um time que só lia a especificação. Nasce a indústria de PC compatível. Fonte.
• 1992: Andrew Tridgell cria o Samba farejando pacotes SMB. No mesmo ano, Sega v. Accolade e Atari v. Nintendo firmam nos EUA que desmontar código pra chegar em elementos funcionais é fair use, uso justo (a Atari perdeu o caso dela por outro motivo: mentiu pro Copyright Office pra conseguir o fonte).
• 1993: começa o Wine, que vira a base do Proton e de todo jogo de Windows que roda no Steam Deck hoje.
• 1999: UltraHLE roda jogos comerciais de N64 em velocidade real; o bleem! emula PS1, a Sony processa e perde as liminares, e o bleem! ainda assim fecha em 2001; o DeCSS quebra a proteção do DVD.
• 2000: Sony v. Connectix decide que copiar a BIOS do PS1 pra construir um emulador é uso justo.
• 2002 e 2003: nascem PCSX2 e Dolphin, os dois emuladores que vinte anos depois ainda são referência.
• 2007: o iPhone é aberto onze dias depois do lançamento. A Comissão Europeia obriga a Microsoft a documentar seus protocolos de rede, e a equipe do Samba recebe a documentação por 10 mil euros.
• 2010: o grupo fail0verflow mostra no 27C3 que a Sony assinou o firmware do PS3 com um nonce fixo, expondo a chave privada (o nonce é o número que deveria ser aleatório em cada assinatura). Dias depois, já em 2011, o geohot publica a chave, a Sony processa e faz acordo em março.
• 2011 e 2013: nascem RPCS3 (PS3) e Xenia (Xbox 360), os dois emuladores mais difíceis já feitos, por motivos que vou explicar.
• 2019: a NSA libera o Ghidra como código aberto. A decompilação do Super Mario 64 vaza e vira pública, e no ano seguinte aparece o port pra PC.
• 2021 e 2022: Ocarina of Time 100% decompilado depois de quase dois anos de trabalho; o Ship of Harkinian vira o port de referência.
• 2024: Mr-Wiseguy lança o Zelda 64: Recompiled, a primeira vitrine da recompilação estática de N64.
• 2025: Sonic Unleashed Recompiled traz o mesmo truque pro Xbox 360, convertendo PowerPC pra C++ e shaders pra HLSL.

Repare que a fase atual, decomp e recomp em escala, começa em 2019, bem antes de qualquer agente de código. A IA entrou numa linha de montagem que já existia.

As ferramentas

O ferramental também é maduro, e boa parte é gratuita:

• IDA Pro (Hex-Rays), o disassembler e decompilador comercial de referência, de mil a quase nove mil euros por ano, com uma versão gratuita limitada a x86.
• Ghidra, a resposta aberta da NSA, com decompilador e scripting, Apache 2.0.
• Binary Ninja, com uma edição gratuita e licenças de 200 a 3.500 dólares.
• radare2 e o Cutter, interface do rizin, que é um fork do radare2: a linha de comando e a interface abertas.
• x64dbg e WinDbg no Windows, GDB no resto.
• Frida, pra injetar código em processo vivo e observar o que ele faz.
• JADX pra Android e ILSpy pra .NET.

Guarde essa lista. O REA, que a gente vai ver daqui a pouco, é um embrulho em volta dela.

Como se desmonta um binário, na prática

Em princípio, todo binário é reversível. O processador precisa conseguir executar aquilo, então as instruções estão lá. O caminho é sempre o mesmo:

1. Desmontar: o binário vira assembly, uma instrução de máquina por linha. Isso é mecânico.
2. Decompilar: o assembly vira algo parecido com C. Ghidra e IDA fazem isso razoavelmente bem, com muito ruído.
3. Recuperar o que o compilador jogou fora: nome de variável, nome de função, tipos, estruturas, comentários. Nada disso sobrevive à compilação. Esse é o trabalho de verdade, e é humano.
4. Refatorar até virar código que uma pessoa consegue ler, manter e portar.

Os projetos de decomp de N64 fazem o passo 4 até o fim: o código em C deles, recompilado, gera byte a byte a ROM original. É assim que o Super Mario 64 virou um projeto com 135 mil linhas de C de código de jogo (uns 100 mil de código efetivo, mais meio milhão de linhas de dados de fase e modelo gerados), e o Ocarina of Time passou de 430 mil linhas. A recompilação estática pula parte disso: traduz as instruções do processador original pra C genérico, sem tentar entender, e troca só as partes que falam com o hardware. É mais rápido e o resultado é menos legível.

“Mas a IA não pode ler o binário direto?”

Alguém sempre pergunta: se é IA, pra que passar por C? Deixa o modelo ler o binário e construir em cima. A resposta curta é que LLM só sabe o que estava no corpus de treino, e corpus de binário pareado com código fonte é escasso, porque nenhum humano escreve assembly de produção há décadas.

A resposta longa é que existe literatura, e ela é instrutiva justamente por ser modesta. A linhagem vai de redes neurais de 2018 a modelos como o SLaDe (200 milhões de parâmetros, um por arquitetura e nível de otimização), o LLM4Decompile (até 33 bilhões) e o Nova. A Meta publicou um LLM Compiler que traduz assembly pra IR do LLVM. Os melhores resultados, em funções isoladas de benchmark, giram em torno de 60 a 65% de código que roda de novo e dá o mesmo resultado, caindo forte quando o compilador otimizou com -O3.

Dois estudos recentes mostram o estado real. O DecompileBench, com 23 mil funções reais, achou que decompiladores baseados em LLM produzem código mais legível e com metade da correção funcional dos decompiladores comerciais. E um trabalho de setembro de 2026 mediu que o refinamento por LLM da saída do Ghidra sobe a taxa de compilação de 75% pra 90% e derruba a fidelidade de comportamento de 74% pra 62%, com até uns 10% das funções com vulnerabilidade conhecida deixando de reproduzir a falha, ou seja, o bug sumiu sem ninguém pedir.

Resumindo o que existe: modelos pequenos, função por função, quase só x86-64 Linux, e os melhores são camadas de refinamento em cima do Ghidra, o que mantém o decompilador clássico no loop. Nenhum emulador, nenhum jogo, nenhum programa inteiro foi recompilado neuralmente. Enquanto alguém não inventa isso, você trabalha com a realidade, e a realidade inclui a camada intermediária de linguagem de programação e compilador.

Os assistentes de IA que existem pra isso em produção confirmam o desenho: o aiDAPal, plugin de IDA da Atredis, o Sidekick do Binary Ninja, os servidores MCP pro Ghidra. Todos são um LLM dando nome a variável e explicando função em cima do que o decompilador tradicional produziu.

O que o REA faz de verdade

Eu clonei o REA e li o código. Ele é um servidor MCP e uma CLI em TypeScript que embrulha as ferramentas da lista acima e as expõe pro seu agente de código: Ghidra, Hopper, IDA, JADX, Frida, Wakaru pra JavaScript ofuscado, Playwright pra capturar o que um site faz. O agente pede, o REA roda a ferramenta e devolve pseudocódigo, grafo de chamadas, strings e traces de IPC, cada resultado com um registro de evidência e uma lista de limitações.

Esse fluxo eu já tinha feito na mão, meses antes de o REA viralizar. Em julho eu coloquei o Fable 5 pra analisar o código do TikTok, do Clash of Kings e do gov.br: baixei os APKs, descompactei (APK é um zip), rodei o JADX nos .dex e deixei o modelo ler o Java que saiu do outro lado. Deu pra ver os endpoints, as permissões, os SDKs embutidos e como cada app monta o fingerprint do aparelho, aquele identificador persistente que sobrevive a limpar dados e reinstalar. O TikTok saiu como coleta de grau industrial, blindada contra auditoria; o gov.br, como exemplo de como fazer direito.

As três lições daquele post valem pro REA inteiro. Android é fácil demais de descompilar, e mesmo assim o resultado serve só pra análise estática, porque recompilar o app fica fora de alcance: os nomes vêm embaralhados pela ofuscação, faltam recursos e chaves de assinatura. A parte mais sensível mora em código nativo, .so em C e C++, que descompila em nada legível, e no TikTok é justamente aí que fica o miolo. E o que saiu daquele trabalho foi um relatório sobre o que o app faz, com ressalvas, e nenhum clone do TikTok. O REA embala esse mesmo fluxo num servidor MCP; as paredes continuam no mesmo lugar.

Quem fornece o julgamento é o LLM que você já paga. O REA fornece o encanamento determinístico e a proveniência. A frase “automatiza as heurísticas de engenharia reversa”, que circula por aí, não aparece em lugar nenhum do repositório; a descrição que o próprio projeto usa é engenharia reversa dirigida por agente, com evidência rastreável.

O que ele exige: o artefato na sua máquina (binário nativo, app Electron, assembly .NET, APK, firmware, captura de rede), Node 22.19 ou superior, e as ferramentas pesadas instaladas por sua conta. Ghidra é grátis; IDA, Hopper e JEB o README manda você comprar. Não tem chave de API do REA porque ele roda local, e o custo de token cai inteiro na sua assinatura de agente.

E esse custo é o detalhe que ninguém cita. O catálogo de ferramentas MCP do REA tem 2,3 MB de JSON, que entra no contexto do agente. O próprio projeto publica um experimento em que analisar o SQLite compilado em WASM, no caminho padrão, levou 42 chamadas de ferramenta, cinco minutos e 300 mil tokens de entrada. Um inventário completo de um app Electron como o Obsidian devolve quase 1 MB de JSON.

Tem issue aberta reclamando que inspecionar um app de Mac comum devolve de 80 a 230 mil tokens de uma vez.

O projeto é sério e vai longe: seis meses, 2.600 commits, mil arquivos de teste, versão 6.4 lançada em 11 de outubro. Também é instável: 190 issues abertas, várias mudanças incompatíveis a cada versão menor, subsistemas marcados como experimentais.

Os limites estão escritos no próprio repositório. O CONTRIBUTING exclui quebra de DRM, anticheat, licença e proteção comercial. O DISCLAIMER avisa que decompilação, reconstrução e análise assistida por IA “podem ser incompletas ou incorretas”. E até as instruções internas pra gerar as figuras do site dizem, com todas as letras: “nunca implique que o REA clona um programa automaticamente” e “nunca diga reconstrução completa, clone exato ou recuperação automática de código fonte”.

O REA é uma boa caixa de ferramentas pra quem já sabe fazer engenharia reversa e quer um agente segurando o Ghidra. Ele não é o botão “copia esse app pra mim”. Quem escreveu o projeto é o primeiro a dizer isso.

PhotoCraft: print bonito, alpha por dentro

O repositório do PhotoCraft foi criado em 30 de setembro. Em duas semanas, 54 mil estrelas, 8 versões lançadas e, no momento em que escrevo, mais de 800 issues abertas. O selo no README diz “early alpha”, e o próprio Brandon Thomas, citado pela Gizmodo, disse que não está nem perto de pronto. A imprensa que testou chegou na mesma conclusão: a Gizmodo chamou de “Photoshop cheio de bug, mas real”, e o OMG Ubuntu de “fac-símile superficial com falhas pronunciadas”.

As issues contam a história técnica:

• Qualquer imagem acima de 8.192 pixels sai do compositor de GPU e cai pra CPU, com pico de 6 GB de memória, porque o limite de textura do egui-wgpu é esse (issue 49, já fechada, e as que vieram depois, 1015 e 4017).
• Uma foto de 12 megapixels precisa de quase 800 MB só pra abrir, ajustar e exportar pela linha de comando (issue 1637).
• O gerenciamento de cor é rudimentar: espaço de trabalho só global, em vez de por documento, e sem transformação de visualização (issue 321). Dezoito issues mencionam CMYK, quinze mencionam perfil ICC.
• Quase cem issues abertas mencionam PSD. Camadas de matiz e saturação compõem diferente do Photoshop, e salvar por cima sobrescreve a imagem mesclada correta do arquivo original (issue 4089).
• Cinquenta issues abertas mencionam “crash”.

A interface lembra o Photoshop, então o print é compartilhável, e quem vê o print assume que é cópia carbono. Isso é esperado numa alpha de duas semanas. Com interesse, tempo e contribuição, parte disso vai sendo resolvida. E aí os contribuidores vão descobrir uma coisa que os projetos de N64 nunca enfrentaram.

O PhotoCraft hoje é aquela réplica de Ferrari montada em cima de um Fusca: a carroceria tem a forma certa, você tira uma foto e a maioria das pessoas diz “uau, uma Ferrari”. Aí você liga e sai o motor de Fusca. Se você se empolgou com a foto, o problema foi seu.

O alvo se move

Decompilar o Zelda de 1998 é mirar num alvo parado. A Nintendo não vai lançar o Ocarina of Time 2026 com formato de arquivo novo. Copiar um produto vivo é outra conversa, e a gente já viu esse filme.

Nos anos 90 e 2000 o alvo era o Microsoft Office. O StarOffice virou OpenOffice em 2000 e LibreOffice em 2010, e todos eles passaram anos correndo atrás de um formato binário, o .doc, que mudava de versão pra versão e só ganhou especificação pública em 2008, quando o jogo já tinha acabado. A parte comprovada dessa história está nos processos: a Comissão Europeia multou a Microsoft em 497 milhões de euros em 2004 por recusar informação de interoperabilidade, e em 899 milhões em 2008 por descumprir a ordem. O .docx só virou padrão ISO em 2008, numa votação tão controversa que países protestaram formalmente.

Levou mais de dez anos. E quando o formato finalmente abriu, o Office já não importava do mesmo jeito. O valor mudou de lugar: hoje são 400 milhões de assentos pagos de Office 365, 3 bilhões de usuários de Google Workspace e uns 41 milhões de assinantes de Creative Cloud. Ninguém quer instalar aquilo no desktop, e por isso ninguém tem o binário.

Fazer engenharia reversa do Google Docs é reescrever o produto do zero olhando só pra interface, porque o código que importa nunca sai do servidor. Depois que o mundo migrou pra SaaS, a maior parte do software proprietário virou jardim murado sem binário. Sem binário, não tem o que desmontar.

Dá pra fazer versões disso, claro. O Immich substitui o Google Photos pra uma pessoa ou uma família: backup do celular, reconhecimento de rosto, busca semântica, tudo no seu servidor. O que ele não replica é a infraestrutura e o corpus de treino que fazem a busca do Google ser a busca do Google. E a Adobe fez a mesma migração, em pedaços.

Photoshop é muito mais que camada e crop

Aqui entra a parte que eu conheço por ter pagado. As features que vendem assinatura hoje nem rodam no seu computador.

O Generative Fill e o Generative Expand rodam no Firefly, na nuvem, e consomem créditos generativos. Vários Neural Filters, segundo a própria documentação, precisam de internet porque o processamento é no servidor da Adobe. A seleção de objeto por IA tem, desde 2020, uma opção de processar na nuvem pra refinar o resultado. Isso tudo é código que não existe na sua máquina pra ninguém desmontar.

Depois vem o que está no binário, mas levou décadas e parceria pra existir. O Camera Raw carrega perfis de correção de lente e perfis de cor por câmera pra centenas de modelos, construídos ao longo de vinte anos e atualizados a cada lançamento. Clone nenhum adivinha isso. Ou tem o dado, ou não tem.

E tem a ciência de cor. O exemplo que eu sempre lembro é o GIMP e o CMYK.

O GIMP nasceu em 1995. O primeiro suporte nativo a arquivo CMYK chegou em 2022, e só de importação e exportação, com o pixel sempre em RGB. O GIMP 3.0, de 2025, ainda sem modo de edição em CMYK. Está no roadmap como trabalho em andamento.

Trinta anos de projeto aberto, com gente boa e motivada, e a gráfica ainda pede o Photoshop. Isso é o tamanho do buraco da ciência de cor, e nenhum agente de código inventa ciência de cor: ele reproduz o que está no treino.

Por que demorou tanto, se era a feature mais pedida? Porque o núcleo do GIMP nasceu com RGB de 8 bits por canal embutido em cada camada, modo de mesclagem e filtro. Suportar outro modelo de cor exigiu reescrever o motor de pixel inteiro, a migração pro GEGL, que levou a maior parte de uma década e só ficou pronta no GIMP 2.10, em 2018. O CMYK só pôde começar depois disso.

E CMYK é uma família de perfis de dispositivo, com quatro tintas, perfil ICC por impressora, limite de tinta e regra de geração de preto, e editar nele significa que toda a cadeia precisa calcular num modelo subtrativo de quatro canais e ir e voltar pelos perfis sem desviar a cor. Um desenvolvedor sozinho, por melhor programador que seja, sem experiência nessa área específica, vai sofrer pra implementar isso, porque o conhecimento está na gráfica e no laboratório de cor, e quase nada dele está em corpus de treino. No GIMP, quem levou a coisa adiante foram contribuidores que entendem de impressão, e mesmo assim foram anos. Ferramenta nova nenhuma atalha esse tipo de conhecimento.

E tem a camada que nem é técnica: licença comercial. Cor de gráfica é Pantone, e Pantone é uma biblioteca proprietária. Projeto aberto nenhum pode embarcar as paletas; os desenvolvedores do Inkscape chegaram nessa conclusão em 2005, e a Linux.com explicou o risco jurídico na mesma época. A própria Adobe sentiu isso em 2022: quando a Pantone mudou o modelo de negócio, as bibliotecas saíram do Photoshop, do Illustrator e do InDesign, arquivos antigos passaram a abrir com as cores Pantone trocadas por preto, e quem precisa delas paga uma assinatura separada de plugin. Se nem a Adobe, pagando, escapou, imagine um clone que vive de boa vontade.

Vídeo é pior

No Premiere, no After Effects e no DaVinci Resolve, o problema multiplica. Câmera de cinema não entrega vídeo, entrega dado bruto numa curva logarítmica própria: LogC4 da ARRI, IPP2 da RED. Pra transformar aquilo em imagem, você precisa das transformadas do fabricante, e a RED entrega as dela num SDK que os editores integram e atualizam a cada versão. O ACES, o padrão neutro da indústria, depende de transformadas de entrada fornecidas por cada fabricante.

A Blackmagic dá o Resolve de graça e ele decodifica ARRIRAW e R3D. Faz isso porque paga o SDK e a parceria por você. Um clone feito por agente, “adivinhando” como a imagem da Alexa deve ficar, produz uma imagem que não bate com o monitor de referência, e no cinema isso significa que não serve. Esse conhecimento não está em corpus de treino nenhum: está em contrato.

O caso Bun: quanto custa reescrever software grande

Pra ter noção de ordem de grandeza, o melhor dado público que existe é o do Bun. Em maio de 2026, Jarred Sumner reescreveu o runtime inteiro de Zig pra Rust usando agentes, e em julho publicou os números:

• 535 mil linhas de Zig em 1.448 arquivos viraram um diff de um milhão de linhas de Rust, em 11 dias.
• Até 64 instâncias de Claude em paralelo, 24 horas por dia, cada linha revisada por dois agentes adversariais e um corretor.
• 5,9 bilhões de tokens de entrada não cacheados, 690 milhões de saída, 72 bilhões de leituras de cache: uns US$ 165 mil a preço de API.
• 16 mil erros de compilador corrigidos por 64 agentes antes do CI ficar verde em seis plataformas.
• A suíte de testes existente, com mais de um milhão de asserções, passou 100% antes do merge.

Lê de novo o que viabilizou isso:

• o autor original do projeto pilotando
• um código fonte completo e funcional como referência
• uma suíte de testes de um milhão de asserções servindo de oráculo
• orçamento ilimitado, porque o Bun pertence à Anthropic desde dezembro de 2025, e uma versão pré-lançamento do Claude Fable 5

O Sumner estima que três engenheiros com contexto total levariam um ano.

Agora tira cada uma dessas vantagens. O PhotoCraft não tem o fonte do Photoshop pra portar, tem que inventar. Não tem suíte de testes que diga “isso aqui bate com o Photoshop”. Não tem o autor do Photoshop.

E o Photoshop é um produto de 36 anos, cujos requisitos de disco a Adobe lista entre 10 e 100 GB, contra um runtime de JavaScript. Mesmo sem saber o tamanho do código da Adobe, estamos falando de um alvo maior, sem referência, sem oráculo e sem dono. Ordens de grandeza acima de US$ 165 mil, e ainda assim seria uma aproximação.

Por que o retrô anda tão rápido

Se é tão difícil, por que sai port de jogo antigo todo dia? Porque o retrô acumula todas as vantagens que o resto não tem.

O binário está disponível e é minúsculo. Super Mario Bros. do NES: 40 KB. Super Mario 64: 8 MB. Ocarina of Time e Majora’s Mask: 32 MB cada. Um CD inteiro de PS1: 650 MB.

Compare com Baldur’s Gate 3, 150 GB, ou com o Call of Duty mais recente, acima de 100 GB. São três ou quatro ordens de grandeza, e o escopo encolhe junto: um jogo de 1996 tem um punhado de sistemas, não um motor de física com rede, loja e anticheat.

A tecnologia é antiga e documentada. Vinte e cinco anos de comunidade já mapearam o hardware do N64, do PS1 e do SNES instrução por instrução. O agente não descobre nada; ele acelera um trabalho com mapa pronto. É o mesmo padrão que eu vi nos meus projetos de retrocomputação: onde tem referência e oráculo, a IA voa; onde não tem, ela gira em força bruta.

O alvo não se move. Ninguém vai atualizar o Zelda de 1998.

E o jurídico está resolvido há trinta anos. Sega v. Accolade e Sony v. Connectix deram o contorno. Os ports exigem que você forneça a sua ROM.

Console moderno é um PC

A segunda metade da explosão, os ports de PS4, PS5, Xbox One e Switch, tem outra explicação: esses consoles são PCs ou celulares com outro invólucro. O PS4 usa um AMD Jaguar x86-64, o PS5 um Zen 2, o Xbox Series outro Zen 2, o Switch um Tegra X1 ARM da NVIDIA. O processador do seu PC roda aquele código nativamente. Então ninguém precisa emular a CPU.

O trabalho que sobra é traduzir o sistema operacional e a GPU. O shadPS4 reimplementa as bibliotecas do sistema do PS4 e recompila os shaders: os jogos saem da fábrica com código de máquina da GPU AMD, que o emulador decodifica instrução a instrução e converte pra SPIR-V, o formato do Vulkan.

O Azimuth, que faz o Forza Horizon 2 rodar no Windows, traduz chamadas WinRT do Xbox pra Win32 e DirectX 11.X pra DirectX 12 desktop, com o código x86 do jogo rodando direto. O AnyPS5 religa o executável: pega o binário do PS5 e gera um binário nativo de Linux ou Windows, ligado a bibliotecas de sistema reimplementadas. Nos três casos, Proton, DXVK, VKD3D e MoltenVK já tinham resolvido a camada de tradução gráfica anos antes.

A prova inversa são os consoles que não eram PC. O PS3 usa o Cell, um PowerPC com sete coprocessadores ativos (os SPEs), cada um com memória local própria e sem cache, e o RPCS3 está nisso desde 2011, com a emulação dos SPUs sendo gargalo até hoje. O Xbox 360 é PowerPC também, e por isso o Sonic Unleashed precisou do XenonRecomp traduzir PowerPC pra C++. Engenharia reversa é caso a caso, e a arquitetura decide se o caso é fácil.

A IA está no meio, e já tem briga

Que os ports de 2026 usam IA, boa parte deles diz na cara. O decomp do Silent Hill escreve no README que o desenvolvimento é “fortemente assistido por IA (Claude Opus 4.6, 4.7 e o Fable mais novo), e somos abertos sobre isso. Não é tradução automatizada do jogo”. O recomp do Pokémon Stadium lista o Claude como contribuidor.

Os devs dos recomps de Zelda e Banjo, que passaram anos fazendo isso à mão, entraram em guerra com o que chamam de “slopcomps”, ports gerados por agente com qualidade de alpha.

E vale separar manchete de estado real também aqui. O AnyPS5 tem uma versão 0.1 de setembro que, segundo quem testou, roda um jogo indie 2D; a alegação viral de que “o PS5 está 80% portado pra PC” é dos fãs, e nenhum jogo 3D roda. Astro Bot roda, só que em emuladores (KytyPS5, SharpEmu), que fazem o caminho tradicional. O Forza Horizon 2 roda, e o Azimuth é um binário fechado de um estúdio que se declara “AI assisted” sem dizer mais nada.

“Mas daqui a dois anos o token custa nada”

A resposta padrão pra tudo isso é: hoje é difícil, em dois anos é trivial, porque IA cresce exponencialmente. Os números dizem outra coisa.

O preço da ponta mais cara caiu pouco. O GPT-4 de março de 2023 custava US$ 30 e 60 por milhão de tokens de entrada e saída; o Claude 3 Opus de 2024, 15 e 75; os modelos de ponta de hoje, Fable 5.1 e GPT-6 Astra, custam 10 e 50. Em três anos e meio, a fronteira ficou entre 1,2 e 3 vezes mais barata, dependendo de qual ponta você olha.

O que caiu de verdade foi o custo de uma qualidade fixa: a Epoch AI mediu quedas de 9 a 900 vezes por ano dependendo da tarefa, e numa revisão de 2026 resume em “muito grosseiramente 5 a 10 vezes por ano”, com o aviso de que pode desacelerar. Isso é real e é ótimo.

Só que aplica a conta no Bun. US$ 165 mil divididos por 10 dá US$ 16 mil. Por 100, US$ 1.650. Isso é pra portar um runtime com fonte, testes e autor na mão.

Pra um amador tentando clonar o Photoshop sem nada disso, a conta começa ordens de grandeza acima e cai na mesma proporção. Barato não é o mesmo que trivial.

E a premissa do “exponencial” morreu em 2024. O Ilya Sutskever disse no NeurIPS que o pré-treino como conhecemos vai acabar, porque só existe uma internet. A Epoch projeta que o escalonamento dos modelos de raciocínio converge pra taxa geral da fronteira em cerca de um ano.

Eu já escrevi sobre isso três vezes nas últimas semanas: os limites do que o modelo reproduz, a convergência dos modelos crus com o ganho vindo do harness, e o benchmark de linguagens em que os modelos de fronteira empataram no teto. A ferramenta que temos é a ferramenta que vamos ter por um bom tempo, com melhoria incremental. Planeje com ela.

Vale lembrar o número que abre o texto dos limites: pelo Octoverse 2025, relatório oficial do GitHub, 81,5% das contribuições na plataforma aconteceram em repositórios privados. É o código que importa de verdade, o que paga salário, e nenhum LLM viu uma linha dele. O modelo reproduz o que estava no treino, e esse código nunca esteve lá.

Agora estenda isso pra todo produto SaaS e pra cada componente que ele usa. O código da Adobe que realmente vale, o motor de cor, os perfis, os filtros na nuvem, não está disponível em lugar nenhum, nem como binário. Quem quiser reproduzir vai ter que refazer a pesquisa e o desenvolvimento, caro e demorado, pelos mesmos anos que a Adobe levou. E no fim ainda esbarra na propriedade intelectual licenciada de terceiros, Pantone, SDK de câmera, perfil de fabricante, que você nunca vai conseguir ter.

Respondendo a lista do começo

O PhotoCraft existe? Existe, é uma alpha de duas semanas com mais de 800 issues abertas, gerenciamento de cor rudimentar, travando acima de 8K e abrindo PSD errado. Parece Photoshop no print. Pode melhorar muito, e vai descobrir que o alvo se move e que as partes caras do Photoshop estão na nuvem ou em contrato com fabricante.

O REA existe? Existe, é bom, e é uma caixa de ferramentas pra quem já sabe usar Ghidra, exige o binário na mão, as ferramentas instaladas e centenas de milhares de tokens por análise. O próprio projeto evita dizer que ele clona programa.

Recomp e decomp aceleraram? Sim, de verdade, e a IA tem parte nisso. Aceleraram onde o binário existe, é pequeno, está documentado há 25 anos e não se move. Ou onde o console é um PC disfarçado e o trabalho é tradução de API, resolvida pelo Wine e pelo Vulkan anos antes.

A Adobe morreu? A Adobe tem uns 40 milhões de assinantes, pela estimativa mais citada, as features que vendem assinatura rodam no servidor dela, e trinta anos de GIMP ainda deixam a gráfica pedindo Photoshop. Eu queria que fosse diferente. Os dados dizem que o que vai acontecer é o que sempre aconteceu com clone de produto vivo: anos correndo atrás, e quando alcança, o valor já mudou de lugar.

Programador morreu? Reescrever o Bun precisou do autor do Bun. Os decomps que funcionam têm gente que conhece o hardware pilotando o agente, e os que não têm viraram “slopcomp” com nome e tudo. A engenharia reversa ficou mais barata e mais acessível, como ficou com o Ghidra em 2019, e continua sendo trabalho de engenheiro. Sem nós, a ferramenta devolve print bonito.

Software proprietário com binário na mão vai sofrer pressão, e deve. A maior parte do software que você usa não tem binário nenhum, e o que tem já depende de serviço na nuvem que não desmonta. Engenharia de software com IA tem um caminho ótimo pela frente. Manchete de “acabou” rende clique e não compila.

É melhor deployar mais rápido, porque corrigir depois ficou rápido e barato.

Essa frase é o artigo inteiro resumido. O resto é só eu justificando por que ela é verdade agora, mesmo não sendo verdade há alguns anos, e mostrando como eu mesmo ajo em cima dela desde fevereiro.

A premissa mudou, e a maioria não percebeu

Comecei a falar isso no X assim:

Corrigir ficou barato. Não segurem coisas mais. Só sobe e corrige depois. “Ain mas corro o risco de subir com bug”. A premissa errada é achar que vc ficar olhando linha a linha vai fazer qualquer diferença num volume grande. E código parado não melhora sozinho. Só código usado dá pra descobrir se precisa melhorar.

E completei no segundo post, porque a primeira leitura de qualquer coisa que eu escrevo em 280 caracteres sempre vem raivosa e literal demais:

Entendam o conceito (é post de X, não de blog, parem de ler literalmente). Não estou dizendo que IA não gera bugs. Gera, óbvio. Mas a esta altura do campeonato, não mais do que você/humano gera também. […] Antigamente a desculpa era que quando sobe em produção com bug, ele fica lá mais tempo do que deveria, porque nunca vira prioridade na sprint pra resolver. Agora NÃO TEM MAIS ISSO, a premissa mudou: corrigir o bug depois é RÁPIDO e BARATO.

Esse é o ponto inteiro. Não é sobre IA ser infalível. É sobre o custo de corrigir um erro ter despencado, e a maioria dos times ainda estar operando o processo de revisão como se esse custo continuasse alto.

Com os modelos de fronteira de hoje, Opus, Sol, K3, e companhia, o LLM erra menos do que a maioria dos desenvolvedores humanos que eu já vi passar por um code review. Quando erra, na esmagadora maioria das vezes o erro não é do modelo. É de quem dirigiu o harness. O LLM faz o que você pede, e não faz o que você não pediu.

Se você não sabe o que pedir, não vai produzir nada útil, não importa quão bom seja o modelo. É exatamente por isso que só Engenheiro de Software de verdade consegue tirar software de produção de verdade de um agente: alguém tem que saber decompor o problema, validar o resultado, e reconhecer quando o pedido em si estava mal formulado. IA não substitui esse julgamento. Ela multiplica o que esse julgamento já sabia fazer.

Isso já era pra ser assim há 25 anos

O incômodo que eu sinto com o processo de review burocrático não é novo, e a indústria já devia ter resolvido isso há muito tempo. Kent Beck e Ron Jeffries inventaram Extreme Programming em 1997, no projeto Chrysler C3, e Beck publicou o livro em 1999 com integração contínua, TDD e entrega em lotes pequenos como práticas centrais. Em fevereiro de 2001, dezessete desenvolvedores se trancaram num resort em Snowbird, Utah, e saíram de lá com o Manifesto Ágil. Isso faz vinte e cinco anos.

O mantra de Martin Fowler pra integração contínua sempre foi “se dói, faça com mais frequência”, e o livro Continuous Delivery, de Jez Humble e Dave Farley, formalizou a ideia de que deploy pequeno e frequente reduz risco, não aumenta. Os relatórios anuais de State of DevOps da DORA documentam isso com número desde a década passada:

• time de elite: deploya sob demanda, várias vezes por dia;
• time de baixa performance: deploya uma vez por mês, às vezes uma vez a cada seis meses.

E o achado mais chato de engolir pra quem tem medo de deployar rápido: historicamente, deploy mais frequente não aumenta a taxa de falha. Reduz. Time que deploya mais, na média dos relatórios da última década, falha menos e recupera mais rápido quando falha.

Mesmo com tudo isso documentado, medido e publicado há mais de uma década, boa parte da indústria continua represando mudança em lote grande, com revisão manual demorada, e chamando isso de “prudência”. Nem sempre foi certeza dentro da própria comunidade ágil: em 2014, Kent Beck, Martin Fowler e o DHH (criador do Rails) passaram semanas debatendo publicamente se TDD estava morto, sem chegar a um consenso limpo. Ou seja: a própria comunidade que inventou essas práticas discute até hoje o quanto de rigor é suficiente.

O que eu estou dizendo é mais simples que essa discussão inteira: seja qual for o seu nível de rigor de teste, o LLM revisando seu diff antes do merge é rápido, e reverter um deploy ruim ficou trivial com container e git. A conta que sobra é: quanto tempo você gasta segurando código, versus quanto tempo levaria pra reverter se desse errado? Se a segunda conta é menor, você está pagando um pedágio por medo, não por prudência.

Não é “suba qualquer coisa”

Essa é a parte que sempre se perde: eu não estou dizendo pra deployar sem nenhuma prática de engenharia por baixo. Estou dizendo o oposto. Isso só é seguro depois que você já tem a engenharia de software básica funcionando, o que eu documento à exaustão neste blog há anos: teste automatizado, CI que roda em todo push, capacidade real de reverter, observabilidade pra saber quando algo quebrou.

80/20. Peça pra LLM fazer uma revisão mínima e sobe. Se quebrar, reverte (pra isso temos containers, git, etc etc). Se não dá pra reverter, sua infra é uma bosta - corrija ela pra ontem.

Essa última frase é o filtro inteiro. Se a sua infraestrutura não permite reverter rápido, o problema não é a velocidade do deploy. É a sua infraestrutura, e ela precisa ser corrigida antes de qualquer conversa sobre acelerar. Ninguém está liberado pra pular a etapa de ter rollback de verdade. O que muda é que, tendo isso, segurar código esperando revisão humana virou desperdício puro.

O ambiente mínimo recomendado

Eu já falei “engenharia de software básica” várias vezes neste texto sem detalhar o que isso significa na prática. Aqui está a lista, sem enrolação. Nenhum item aqui é opcional, e nenhum deles ficou caro de manter:

• teste unitário cobrindo a lógica isolada, TDD ou não, contanto que exista;
• teste de cenário e integração cobrindo concorrência, falha parcial e conflito, o que teste unitário sozinho não pega;
• CI que builda e testa em toda mudança, de preferência pras plataformas que você realmente publica;
• revisão automática hostil antes do merge, tipo pr-audit, que trata alegação do contribuidor como não verificada até prova;
• feature flag pra controlar o raio de explosão de quem vê a mudança primeiro;
• staging de verdade como gate antes de qualquer usuário real ver a mudança;
• capacidade de reverter rápido, com git e container, e observabilidade pra saber quando algo quebrou;
• em ambiente de compliance, financeiro ou de saúde, uma camada extra: teste de cenário mais pesado, e mais de uma trava por modo de falha identificado.

O que o diagrama tenta deixar claro é que velocidade e segurança não competem entre si aqui. Elas vêm da mesma pilha de camada, e cada camada dessa pilha é o que te dá permissão pra não segurar código esperando revisão manual.

Onde essa conta não fecha

Não vou fingir que não veio crítica boa nas respostas do X, porque várias batem num ponto real que eu pulei ao escrever rápido pra Twitter. Vale mais responder de verdade do que só validar quem concordou.

1. Reverter código não desfaz consequência que já saiu do seu sistema. Se o bug já processou um pagamento errado, moveu dinheiro pra conta errada, ou controlou um elevador, reverter o deploy não desfaz o que já aconteceu. “Se não dá pra reverter, sua infra é uma bosta” cobre a parte técnica de deploy e rollback, não o caso onde o dano já saiu do seu sistema antes de você conseguir reagir. Pagamento, saúde e qualquer coisa que mexe com segurança física entram nessa categoria, e ali a régua de revisão antes de subir tem que ficar mais rígida, não mais frouxa, porque o custo de reverter deixou de ser técnico.

2. Banco de dados quebra a analogia de “reverter é fácil”. Reverter um binário é trivial. Reverter uma migration que já rodou em produção, já moveu dado, e talvez já apagou coluna, não é. Existe um padrão pra isso, expand-contract: adiciona o novo formato sem remover o velho, espera todo consumidor migrar, só depois remove o velho. Isso não é sobre confiar mais ou menos em IA. É sobre estado que não se desfaz com git revert.

3. Biblioteca e pacote público não seguem a mesma conta que aplicação fechada. Quando o meu código quebra, eu conserto na hora. Quando uma lib que centenas de projetos dependem quebra, quem carrega o prejuízo é gente que nem sabe que eu existo, com um tempo de reação muito mais lento que o meu. É por isso que a minha skill de pr-audit, que eu descrevo mais abaixo, trata classificação de semver como gate de versão: breaking change anda em major, nunca em patch, porque ali a revisão de verdade não é sobre pegar bug, é sobre não surpreender quem depende de você sem avisar.

4. Loja de app derruba a velocidade também, e o meu próprio exemplo do frank_yomik esconde isso em vez de resolver. Ele publica o APK direto como GitHub Release, sem passar pela Play Store. Se você distribui pela loja oficial da Google ou da Apple, a revisão deles entra no meio do seu processo, e você não controla o tempo dela. Este artigo é sobre remover o gargalo que está dentro do seu controle. A loja de app não está dentro dele.

5. O ponto mais honesto de todos: toda evidência que eu trago aqui vem de projeto onde eu sou o único dono e decido sozinho. Não tenho como provar, com meus próprios números, que o mesmo ritmo funciona dentro de uma empresa grande, com Jurídico, Compliance e gerente de produto no meio do caminho. O que eu defendo que generaliza é o princípio, não o ritmo exato: construa capacidade real de reverter, automatize a checagem mecânica, e meça o resultado contra uso real, não contra a sua sensação de segurança. Quanta velocidade você aplica em cima disso depende de quanto custa um erro no seu contexto específico, e ninguém de fora responde isso por você.

Sobre o primeiro ponto especificamente, vale abrir mais, porque “régua mais rígida” não pode ficar vago. Isso significa teste de cenário real, não só teste unitário. O próprio ai-memory tem mais de mil testes de integração espalhados pelos seus módulos, e a maioria não pergunta “essa função devolve o valor certo?”. Pergunta coisa como:

• o que acontece quando duas escritas concorrem pelo mesmo arquivo ao mesmo tempo;
• o que acontece quando o disco falha no meio de uma operação de exclusão;
• o que acontece quando duas sessões tentam consolidar o mesmo dado ao mesmo tempo;
• o que acontece quando o processo morre antes de terminar de escrever.

Ambiente com exigência de compliance, financeiro ou de saúde, precisa desse nível de teste: todo modo de falha identificado tem que ter mitigação, e mais de uma camada de checagem, nunca uma trava só.

E aqui está o ponto que sustenta o argumento inteiro deste artigo mesmo nesses ambientes: essa exigência não muda dependendo de quem escreveu o código. Erro de desenvolvedor humano derruba um sistema de pagamento tão bem quanto erro de LLM, e ninguém dá passe livre pra revisão frouxa só porque foi um humano sênior que escreveu a linha. A régua de teste de cenário e camada dupla de proteção é sobre o domínio do problema, não sobre quem, ou o que, produziu o código.

Feature flag e ambiente de staging são a outra metade dessa camada dupla, e eles também mudaram de custo. Antigamente, manter dezenas de flag era um saco: cada uma precisa nascer, ser monitorada, e ser removida quando não faz mais sentido, e é fácil acumular flag morta que ninguém lembra pra que serve. Isso ficou barato também: peço pro agente auditar todo flag do projeto, achar qual está travada no mesmo valor há meses, e gerar o PR de limpeza. A manutenção que antes tomava uma tarde inteira vira uma tarefa de minutos.

Com isso resolvido, a defesa em camada fica simples de montar: staging pra pegar erro óbvio antes de qualquer usuário ver, feature flag pra limitar o raio de explosão de quem vê a mudança primeiro, e teste de cenário pra cobrir o que staging sozinho não simula. Três camadas, nenhuma delas cara de manter.

Como eu faço isso desde fevereiro

Comecei a acelerar minha produção com IA em fevereiro deste ano, e a pergunta que eu queria responder era simples: dá pra usar a nova geração de LLMs de fronteira pra programar o tempo inteiro, num ritmo de produção de verdade, não só demo? A resposta virou meu maior benchmark de LLMs, mais de 110 artigos publicados desde então, e isto, como eu escrevi recentemente:

Desde fevereiro produzi mais de 110 artigos no meu blog. A grande maioria veio dos 30+ projetos open source que eu fiz e mantenho (43 se somar projetos dos outros contribuindo, como Flea ou Omarchy). 1.6 milhão de linhas de código produzidos. Eu sozinho (com agentes, claro).

Os projetos que eu mais uso no meu próprio dia a dia, e que sobreviveram ao teste de “eu continuo mantendo isso meses depois”, são três:

• ai-jail: sandbox de SO pros meus agentes de código;
• ai-memory: memória de longo prazo pros agentes;
• ai-usagebar: widget de barra pra monitorar consumo de LLM.

Dois deles já têm landing page decente:

O ai-jail subiu hoje. O ai-memory está no ar em aimemorybr.netlify.app porque a transferência do domínio aimemory.io ainda vai levar mais alguns dias.

As duas rodam no Netlify. Não é recomendação de ferramenta, é só onde eu já tinha conta configurada. O ponto que importa aqui não é a plataforma, é o fluxo: pra colocar uma versão nova no ar, o comando é git push. Não existe passo manual entre o commit e o site atualizado.

A minha newsletter, The M.Akita Chronicles, já passa de 15 mil assinantes:

E o esforço mais novo é converter os posts do blog em episódio de podcast. Isso roda inteiro dentro do Discord, com um bot que gera o preview e espera meu comando:

Um /publish-podcast 2 depois, o episódio está publicado e a transcrição já tem URL:

Do texto pronto até o áudio publicado, o processo inteiro é eu digitando um comando de barra numa conversa de Discord. Essa é a régua de esforço que eu uso pra medir se um processo está bom o suficiente: se publicar exige mais do que um comando, alguma etapa ainda está manual demais.

E a qualidade do código gerado, aguenta?

Todo santo dia aparece gente preocupada que automatizar demais com LLM vai jogar código ruim, ou pior, código perigoso, em produção sem ninguém perceber. Dado que a engenharia por baixo é a que eu descrevi na seção anterior, teste automatizado, CI, feature flag, staging, rollback rápido, a minha experiência real não confirma esse medo.

Já produzi mais de 1,6 milhão de linhas de código com LLM desde fevereiro. Nunca vi um LLM fazer alguma coisa aleatoriamente destrutiva sem eu pedir. Pelo contrário: no meu LLM Benchmark v4, montei de propósito um cenário adversarial, um subagente plantando catorze sabotagens reais baseadas em CVE, escondidas dentro de um projeto que cresce em sete sprints. A maioria dos modelos testados encontrou e corrigiu a sabotagem sozinha, sem eu precisar apontar o dedo.

Isso é anedótico. Não prova nada além do que aquele benchmark específico mede. Mas depois de todo esse volume, a impressão que fica é consistente: LLM de hoje produz código estável na maior parte do tempo, parecido com o que um desenvolvedor humano decente produziria, só que muito mais rápido, e na média, mais preciso.

CI/CD multiplataforma sem esforço

Fui contar quantos dos meus projetos ai-* e frank-* (18 repositórios no total, entre os que têm README) já têm build e deploy automatizado. Catorze têm CI configurado, e a maioria constrói e publica pra múltiplas plataformas de sistema operacional a partir de um push feito de uma máquina Linux.

O exemplo mais completo é o próprio ai-memory: um único push de tag dispara um workflow que, na mesma execução:

• builda Linux x86_64 e arm64;
• builda macOS arm64 e x86_64;
• builda Windows x86_64, com empacotamento em PowerShell;
• publica uma imagem Docker multi-arquitetura;
• empurra o pacote pro AUR do Arch Linux.

O ai-usagebar segue o mesmo padrão de build pra Linux e Windows, e ainda publica em dois pacotes do AUR, no crates.io, e num bucket do Scoop pra Windows.

E tem o caso do frank_yomik, meu leitor de mangá com OCR e tradução via LLM local, que é o exemplo que eu queria pra mostrar que Android entra na mesma esteira. Um push de tag v* dispara cinco builds em paralelo:

• Linux;
• macOS;
• Windows;
• extensão de navegador;
• Android, num runner Linux comum, decodificando um keystore de assinatura guardado nos secrets do GitHub e gerando o APK já assinado.

No final, um job espera os cinco terminarem e publica um único GitHub Release com todos os binários juntos. Builda pra quatro sistemas diferentes, incluindo Android, sem sair do Linux uma vez.

Nem tudo saiu perfeito na primeira olhada, e eu prefiro admitir isso a fingir que é tudo redondo: o frank_sherlock e o frank_karaoke publicam a release como rascunho por padrão, o que trava a automação seguinte (como o push pro AUR) até alguém clicar em “publicar” manualmente. Achei esse buraco enquanto escrevia este texto.

Um projeto vizinho, o frank_scanlation, já tinha resolvido um problema parecido, mas diferente: o GitHub suprime o evento que dispara automação quando a própria release foi criada pelo token do robô, então o workflow dele dispara a etapa seguinte na mão, via workflow_dispatch, de dentro do próprio job. Nenhum dos dois ajustes é difícil. Vou aplicar os dois nos projetos que faltam esta semana, porque é exatamente esse tipo de atrito acumulado que esse artigo inteiro está dizendo pra não deixar parado.

E já que estamos falando de atrito escondido: o ai-memory tem código específico pra Windows (índice de arquivo NTFS, hook nativo em PowerShell) que só roda de verdade no runner windows-latest do GitHub, uns 1000 segundos contra 250 no Linux pra mesma suíte. Cheguei a montar uma VM Windows local via dockur/windows achando que ia ganhar velocidade.

Não ganhei: o workload é dominado por E/S de disco, e o resultado saiu mais lento que o runner do GitHub pra suíte inteira. Ficou útil só pra iteração rápida num crate isolado. Ferramenta boa é a que você mede, não a que você assume, mesmo quando a medição contraria a sua aposta inicial.

A revisão automática que sustenta tudo isso

Eu já detalhei minhas skills de revisão num artigo recente, então vou resumir aqui:

• pr-audit audita todo PR antes do merge com o princípio de evidence over narrative: nada do que o contribuidor escreveu é verdade até prova, com checklist hostil pra código malicioso, credencial exposta, quebra de semver e tentativa de prompt injection;
• iss-audit aplica a mesma desconfiança pra issue, nunca executando comando colado por quem reportou;
• github-resolution transforma o que foi aprovado em código mergeado, um ticket de cada vez, com teste de regressão escrito antes da correção, e a regra de que “slop é defeito”: sem abstração especulativa, sem TODO esquecido, sem enfraquecer teste pra passar mais rápido.

Isso pega a categoria mais cara de porcaria dentro do mesmo diff. Não pega duplicação espalhada entre PRs diferentes, porque a auditoria olha um diff isolado, não a arquitetura inteira do projeto. Essa parte ainda depende de eu notar o padrão se repetindo e mandar consolidar.

Na minha estimativa, isso resolve uns 99% do trabalho de revisão e resolução sozinho, comigo supervisionando e decidindo os casos que sobram. Só que isso não é o ponto principal. Automação de revisão é necessária, mas ela sozinha não prova nada sobre se o software é bom.

O que realmente mantém isso no chão: gente de verdade usando

Aqui está a parte que eu acho mais importante do artigo inteiro, e que costuma passar batido: a sua própria revisão não vale tanto quanto você acha. O que vale é software publicado sendo usado por gente de verdade, dando feedback de verdade.

Fui checar os números reais do ai-memory no GitHub, sem arredondar pra impressionar:

• issues: 287 no total, 249 vieram de gente que não sou eu, 86,8% do total;
• pull requests: 562 no total, 371 de fora, sendo 10 delas bump automático do Dependabot e as outras 361 vindas de gente de verdade, cerca de 121 contribuidores distintos.

Os dois que mais contribuíram junto comigo mandaram 64 e 43 PRs cada, sozinhos.

Isso é o que mantém o projeto no chão. Não é o LLM sendo bom revisor, nem eu sendo bom revisor. É centenas de pessoas usando de verdade, achando casos que eu nunca imaginei, e mandando issues e PRs reais. Sem isso, minhas skills de revisão automatizada estariam apenas confirmando as minhas próprias suposições de volta pra mim, por mais rigorosas que as regras pareçam no papel.

Não importa o quão boa é a IA que você usa: se ninguém usa o que você publicou, você não tem feedback real, e sem feedback real não existe melhoria real. Só existe a sua própria opinião sobre o próprio trabalho, validada por ninguém além de você mesmo.

A conclusão que interessa

Engenharia de software de verdade precisa ter deploy rápido e de esforço quase zero. Não é opcional, não é luxo de time grande, é pré-requisito. E se revisar e colocar em produção está demorando mais tempo do que desenvolver a funcionalidade, você não está só errado.

Você é o gargalo.

Desculpa e justificativa não valem nada nesse momento. Use esse tempo pra consertar você mesmo e o seu processo, porque só resultado no mundo real importa, não a sensação de segurança de ter revisado linha por linha um diff que ninguém mais vai olhar de novo.

Se a premissa mudou, eu mudo hoje. Não amanhã, não semana que vem. E se a sua ainda não mudou, o problema não é a IA. É você segurando o próprio trabalho.

Soltei este tweet hoje de manhã e ele rendeu. O ponto completo: quando a tecnologia em si vira commodity, o dinheiro migra pra taxonomia. Criam cinco nomes novos pra encadear chamada de API e de repente surge uma certificação que expira em seis meses.

Deixa eu sustentar a provocação com calma, porque ela não é implicância gratuita.

Já antecipo o comentário padrão: “mas comigo funciona”. Bom pra você — de verdade. Só que “funciona comigo” nunca provou que a cerimônia é o que fez funcionar. O que fez funcionar foi você saber o que queria. A cerimônia só estava no mesmo ambiente.

O meu recibo

Entre janeiro e maio eu fiz uma maratona de IA e publiquei mais de 30 repositórios públicos. Tem ferramenta que eu uso todo dia — ai-memory, ai-usagebar, ai-jail — e tem app pessoal pra coçar a minha própria coceira: Frank Manga+, Frank Scanlation, Frank Geary, e por aí vai.

Sabe o que eu nunca senti vontade de fazer nesse meio tempo? Complicar meu setup de IA. Não tenho um Pi super customizado, não tenho Hermes, não tenho grafo de agentes orquestrado, não tenho pipeline de specs numeradas. Graças ao ai-memory, eu troco de harness como troco de cueca: todo dia, sem limitação. Claude Code de manhã, Codex à tarde, Kimi CLI de noite — a memória do projeto vai junto, então o harness vira detalhe.

E detalhe é o ponto. A maioria dos harnesses é otimizada pro LLM da própria casa. Mas “otimizado” não quer dizer “mágico”, e eu tenho dados pra isso.

O que o meu benchmark diz sobre harness

No meu LLM Coding Benchmark eu rodo os mesmos modelos em harnesses diferentes, em condições controladas. O resultado é o oposto do que o mercado de cursos sugere:

• Pra modelo fraco, o harness resgata. O Grok 4.3 não construiu nada no OpenCode pelado (18 pontos) e entregou um app de verdade no grok CLI (55). O Gemini 3.1 Pro saiu de 62 pra 88 no harness do Google — mas o problema ali era um bug de transporte do OpenRouter, não falta de “engenharia de harness”.
• Pra modelo de fronteira, o harness é ruído. Grok 4.5: 92 no OpenCode, 91 no grok CLI. Grok 4.6: 92 e 93. Diferença de um ponto, dentro da margem. Nenhuma engenharia de harness move um modelo bom.
• Onde o harness morde de verdade é no bolso. A rodada do Grok 4.6 saiu por $1,19 no grok CLI contra $6,33 no OpenCode via OpenRouter — mais de 5x mais barato pelos mesmos ~11 milhões de tokens, porque o CLI oficial usa o cache nativo da xAI. Mesma história no Codex: o GPT 5.6 Terra custou $6,77 blended porque 21 dos 21,7 milhões de tokens bateram no cache; o Sol, da mesma família e mesma nota, saiu por uns $45.

Ou seja: escolher um harness decente importa — pra custo e pra dar estrutura a modelo fraco. Mas isso é uma tarde lendo documentação e olhando a fatura de tokens, não uma disciplina nova com trilha de aprendizado.

Já que citei o Hermes lá em cima, vale explicar: o Hermes Agent é um framework open source da Nous Research pra você montar o seu agente pessoal — você define as tools, escreve os loops, configura roteamento por modelo, fallback local/nuvem, gateways de Telegram e Discord, e ele ainda “aprende skills” com o uso. É o paraíso de quem monta setup.

Também é um segundo emprego: cada peça dessas vira sua responsabilidade de manter, atualizar e depurar, pra sempre. E no fim das contas o motor continua sendo o mesmo Claude, GPT ou Qwen de todo mundo — o chassi customizado não melhora o motor. O que o Hermes resolve de verdade, continuidade de contexto entre sessões e entre ferramentas, um harness decente com um ai-memory da vida já cobre — sem você virar administrador de infraestrutura do próprio assistente.

Se você quer um assistente no seu hardware por hobby ou por privacidade, é ótimo motivo, vai fundo. Como pré-requisito de produtividade, não é.

Pra guardar: harness bom é o que cobra menos e não atrapalha. O resto é o modelo. E modelo bom não precisa de “harness engineering” — no máximo precisa que o transporte não esteja quebrado.

Loop Engineering, Graph Engineering, Spec-Driven Development

Vamos aos nomes, porque eles descrevem coisas reais — só que minúsculas.

Loop Engineering é o nome da vez pra projetar o ciclo que um agente repete: executa, verifica com evidência, itera até uma condição de parada. Os guias listam modos de falha reais — o agente declarar “pronto” cedo demais, o objetivo ir derivando a cada volta. Só que a mitigação recomendada é “um verificador independente conferindo evidência objetiva”. Isso tem nome faz cinquenta anos: teste e revisão. Um agente num loop com suíte de testes é o básico de sempre com nome novo.

Graph Engineering é desenhar o workflow do agente como um grafo explícito de nós, ramos e junções — a LangChain tem três anos dessa história. Faz sentido quando o fluxo é genuinamente ramificado. Só que a maioria esmagadora dos projetos é uma linha reta com um if no meio. Modelar isso como grafo é comprar um quadro branco gigante pra desenhar uma seta.

Spec-Driven Development é escrever uma especificação detalhada primeiro e tratar o código como artefato gerado a partir dela — a spec vira a “source of truth” e o código, subproduto. Guarda esse, que o argumento forte vem já embaixo.

Repare no padrão: cada nome pega uma prática real e pequena — rodar em loop com verificação, desenhar um fluxo, escrever o que você quer antes de fazer — e infla até virar “disciplina”. A inflação é o produto. Nome novo cria curso, curso cria certificação, certificação expira em seis meses e te vende a recertificação.

Pra ser justo: os guias sérios desses temas já trazem a ressalva — o guia de graph engineering mais lido diz na cara que “você provavelmente não precisa” e manda dominar o loop antes de abrir um grafo, e a LangChain tem uma seção inteira de “quando não usar grafos”. O guia está certo; o estrago vem do funil, que joga a ressalva fora e vende o resto como default pra todo mundo.

Os dois que mais vendem curso — orquestração pesada de agentes e spec-driven development — merecem mais que definição. Merecem o argumento.

O argumento forte contra a super-orquestração

Tem uma matemática simples que os diagramas de agentes orquestrados nunca mostram. Se cada etapa do seu pipeline acerta 90% das vezes — e isso é otimista —, uma cadeia de dez agentes acerta 0,9^10, ou seja, ~35% das vezes. Cada nó é um ponto novo de falha, e cada aresta é token gasto com agente conversando com agente em vez de trabalhando.

Não precisa acreditar na conta: eu medi isso sem querer no benchmark. O MiniMax M3 rodado debaixo de um orquestrador parecia Tier D, com 24 pontos. O mesmo modelo, limpo, fez 91, Tier A. Uma diferença de até 69 pontos entre condições de harness significa o oposto do que o vendedor de orquestração diz: quando o plumbing domina o resultado, você parou de medir o modelo e passou a medir o encanamento. O melhor resultado de todo o benchmark não veio de nenhum enxame orquestrado: veio de um modelo forte, sozinho, num loop simples — Fable 5, 96 pontos, Claude Code, fim.

Faz sentido quando você lembra que coordenação escala mal. Cada agente a mais não adiciona só capacidade; adiciona arestas, contratos de mensagem, estado compartilhado e versões conflitantes da verdade. O roteador que decide “qual agente cuida disso” vira ao mesmo tempo o gargalo e a fábrica de bugs. Um comitê de agentes medianos com regente não bate um agente capaz com boas ferramentas e memória.

Isso eu já testei diretamente. Em abril eu rodei três rodadas de “modelo forte orquestrando modelo barato” — planner + executor, delegação forçada, o pacote completo. Resultado: nenhuma combinação multi-agente bateu o Opus sozinho num harness maduro. Numa tarefa coesa como construir um app, o planner precisa ler cada output do executor antes de despachar o próximo passo — os dois viram sequenciais, com latência triplicada e uma fila de coordenação no meio. É o comitê de novo: muita conversa, pouco software.

Não é só o meu benchmark. A Cognition, que vende o Devin, publicou o “Don’t Build Multi-Agents” com um mecanismo mais afiado que a minha conta de 90%: toda ação carrega decisões implícitas que os outros agentes não veem — um subagente desenha o fundo estilo Mario, o outro desenha um pássaro incompatível, e nenhuma confiabilidade individual conserta a divergência.

A própria Anthropic, que tem um sistema multi-agente de pesquisa, admite no post de engenharia que multi-agente gasta 15x mais tokens, que coding é um domínio ruim pra isso — a maioria das tarefas de código não é paralelizável de verdade — e que 80% da melhoria deles veio de simplesmente gastar mais tokens, não da arquitetura.

Quando Berkeley mediu o que realmente roda em produção, 86 sistemas em 26 domínios: 68% dos agentes em produção executam no máximo 10 passos antes de intervenção humana. O que existe de verdade por aí é loop simples supervisionado — não a constelação de nós coloridos do diagrama do consultor.

Onde a orquestração é legítima: trabalho genuinamente paralelo e independente — varrer dez mil arquivos, rodar dez mil análises descartáveis. Map-reduce existe faz vinte anos e nunca precisou de nome pomposo. E tem um recanto sério além dele: agente rodando de madrugada, sem ninguém olhando, com credencial na mão — aí verificador independente e orçamento duro viram questão de segurança, não de estilo. Mas isso é operação de frota, não o coding do dia a dia que o curso te vende. Fora desses nichos, a maioria das “arquiteturas multi-agente” é o trabalho de um agente só, com YAML extra.

Tem um motivo pra você ouvir tanto sobre isso: orquestração é complexidade visível. Tem diagrama, tem nó colorido, tem dashboard. Um agente bem dirigido não tem nada disso — não tem slide, não tem certificação, não tem o que vender.

Pra guardar: cada agente a mais multiplica os modos de falha. Se o resultado do seu sistema muda quando você troca o orquestrador, o seu sistema é o orquestrador — e o modelo era figurino.

O argumento forte contra spec-driven development

O SDD parece maduro porque soa como “escrever documentação”. Mas presta atenção no que ele realmente propõe: a spec vira a fonte da verdade e o código vira artefato gerado. O problema é que uma spec precisa o bastante pra gerar código correto já é um programa — só que escrito em prosa, e prosa não compila. Cada ambiguidade da spec é um bug que nenhum compilador pega, num meio sem teste, sem linter, sem feedback. O SDD não remove a parte difícil, que é pensar com precisão; ele move a parte difícil pra um formato onde erro não grita.

Pra guardar: uma spec precisa o bastante pra gerar código correto já é um programa — só que em prosa. E prosa não compila.

Mesmo que você escreva a spec perfeita, ela começa a morrer no primeiro hotfix. O bug aparece em produção, alguém conserta direto no código, e a spec vira mentira. A gente conhece essa lei faz décadas — é por isso que documentação apodrece. Chamar a spec de “fonte da verdade” não muda o incentivo de ninguém.

A gente já fez esse experimento, aliás. UML, MDA, “o código se gera a partir do modelo” — vinte e poucos anos atrás era a mesma promessa com outras siglas. Colapsou sempre pela mesma razão: o modelo nunca era a realidade; o código era. O SDD é o MDA com um LLM pendurado. E não sou só eu que vejo o Waterfall 2.0 ali.

Quem testou as ferramentas com seriedade chegou no mesmo lugar. A Thoughtworks colocou spec-driven development no anel “Assess” do Technology Radar — não “adote”, “avalie” — depois de ver as ferramentas inflarem tarefas pequenas em cerimônia, e cravou a frase que resume: estamos talvez “reaprendendo uma lição amarga: regras detalhadas feitas à mão pra IA simplesmente não escalam”. É a Bitter Lesson do Rich Sutton batendo na porta de novo — estrutura artesanal perde pra escala, sempre perdeu.

Tem ainda a inversão temporal. A grande lição do agile foi que você descobre o que quer construindo — working software over comprehensive documentation. O LLM acabou de deixar a iteração barata como nunca na história. E o que o SDD propõe? Expandir a fase de planejamento, justo agora que iterar ficou barato. Resposta errada, na direção errada, na hora errada.

É a tese que eu venho martelando desde os primeiros posts de Agile Vibe Coding: software emerge, não se planeja. Escrevi isso em fevereiro, com recibo: as features mais importantes do M.Akita Chronicles nasceram de problema que apareceu no meio do caminho — um job que falhou em silêncio, um site que bloqueou a gem, um crash que deixou email em limbo. Nenhum spec do mundo prevê isso. O sistema correto emerge da iteração, não da especificação.

O processo ficou documentado de novo quando o ai-memory cresceu na mão de 26 contribuidores em 24 dias: software bom é escultura de barro, não torre de Lego — maleável, sempre ajustável, nunca pronto. Quem tenta desenhar a arquitetura inteira antes da primeira linha constrói uma camisa de força, não um sistema. Só amador ainda acredita que dá pra especificar o software inteiro antes de codar. Modelagem de verdade não vem de template nem de curso — falei disso anos atrás no Akitando 144: ela nasce de repertório com problema e código reais. Não tem receita pronta; nunca teve.

O SDD tenta ressuscitar a ideia de que dá pra planejar software adiantado — a ideia que a indústria enterrou depois de décadas de projeto entregue atrasado, errado e superfaturado. O LLM não revalidou essa ideia; só deu a ela um PowerPoint novo.

Até quem escreve guia a favor separa as duas coisas: “spec-as-source é onde mora o hype; spec-anchored é onde está o valor hoje”. O meu alvo aqui é o primeiro. Onde a spec pesada é legítima: time grande, codebase legado, trabalho assíncrono que atravessa fuso e sprint — o bom e velho documento de design, que sempre existiu e sempre teve valor. O que não cola é vender isso como o novo default pra todo mundo.

O meu prompt de benchmark, pra constar, é uma página de objetivos. A diferença é que eu não confio na prosa: eu valido rodando. Precisão mora em teste, não em parágrafo.

O que você realmente precisa

Eu já escrevi tudo isso aqui no blog, com recibo de projeto real. Chama Agile Vibe Coding, e cabe num parágrafo:

É XP (eXtreme Programming, o agile raiz) com LLM: testes, Clean Code, CI (integração contínua), pair programming e deploy. Você dirige o agente como dirigiria um pair muito rápido: diz o que quer, acompanha a execução, corrige enquanto o erro é barato. A ideia é 10% do trabalho; os outros 90% são engenharia de software normal, a de sempre. Esquece framework e template de três páginas: o que você precisa é saber o que quer, saber o que não quer, e saber validar quando chega. E precisa de equilíbrio: nem largar o volante pro agente, nem virar fiscal de vírgula.

Foram mais de 600 horas disso, mais de meio milhão de linhas, dezenas de projetos no ar. Nenhum grafo, nenhuma certificação, nenhum loop com nome em inglês.

Pra guardar: a ideia é 10% do trabalho; os outros 90% são engenharia de software, a de sempre.

A peça que me deixa trocar de harness: ai-memory

Tem uma ferramenta minha que é o oposto de taxonomia: o ai-memory. Ele nasceu de um problema concreto. Todo harness guarda a sessão no formato dele, e quando a conversa fica longa, ele compacta o histórico pra caber na janela — e a compactação joga fora justamente os detalhes que explicam por que cada decisão foi tomada. Aí você troca de ferramenta e começa do zero, com o projeto inteiro pra reexplicar.

O ai-memory resolve isso do lado de fora do harness. Ele lê a sessão nativa sem tocar no arquivo original e guarda tudo num ledger pesquisável: mensagens, chamadas de ferramenta com resultados, resumos de compactação, checkpoint do git — cada evento marcado com a origem (veio do Claude, do Codex, do OpenCode). Quando eu abro outro harness, ele ganha a sessão nativa dele e recebe só o delta que ainda não viu. Quando eu volto pro anterior, o ai-memory retoma no formato daquele cliente e entrega o que aconteceu nos outros enquanto isso.

É por isso que “troco de harness como troco de cueca” não é força de expressão. O conhecimento do projeto mora no projeto, não na sessão de uma ferramenta. Se a Anthropic mudar preço, limite ou modelo amanhã — e vai mudar —, eu troco o motor sem jogar fora a viagem. Os detalhes de como isso funciona estão neste post.

Tem ainda uma inversão aqui que despacha o SDD de brinde. O spec-driven development diz que a fonte da verdade é um documento escrito antes do trabalho, tentando prever o futuro, e que o código deve obediência a ele. O ai-memory faz o contrário: a fonte da verdade é uma wiki destilada do próprio trabalho — cada sessão vira evidência, e o que merece sobreviver (decisões, regras, gotchas, tentativas que falharam) é consolidado em páginas Markdown curtas que qualquer agente lê antes de começar.

A spec tenta adivinhar o projeto; a wiki registra o projeto. Documento escrito antes apodrece no primeiro hotfix, porque ninguém é obrigado a atualizá-lo. A wiki é alimentada pelo próprio ato de trabalhar — e quando desatualiza, você percebe na hora, porque os agentes tropeçam nela toda sessão.

Repare que isso é harness engineering de verdade: uma ferramenta, escrita uma vez, resolvendo um problema meu. Nenhum curso, nenhuma sigla, nenhuma certificação.

Conclusão: pede o recibo

Não gaste tempo nem dinheiro com curso de “harness engineering”, “loop engineering” ou qualquer taxonomia da semana. É tentativa descarada de te cobrar por coisas que você já faz se souber engenharia de software básica.

Esse filme a gente já viu, aliás. O Pedro Arantes lembrou no X: “Microservices, clean architecture, hexagonal e Domain-Driven Design são tudo bullshit pra vender mais horas de consultoria e cursos.” Mesma história, mesmo roteiro. Cada um deles nasceu de um problema real — e virou default de quem não tinha o problema. Microservice pra time de três pessoas, arquitetura hexagonal pro CRUD (o cadastro cria-lê-atualiza-apaga de sempre), DDD pra nunca mais escrever código. A técnica passa, a taxonomia fica, o curso vende.

Pra ninguém se fazer de desentendido: nada disso é inútil. Loop com verificação funciona. Grafo funciona quando o fluxo é um grafo de verdade. Spec pesada salva time grande. Microservices resolveram problemas reais de quem tinha escala de verdade; DDD brilha em domínio complexo de verdade. O problema nunca foi a ferramenta — é vender a ferramenta como bala de prata, o martelo universal que você precisa aplicar em tudo. Bala de prata não existe, nunca existiu. Quem te vende uma não está vendendo solução; está vendendo curso.

Entenda o mecanismo psicológico, porque ele é velho e eficiente: esses termos existem pra te dar FOMO (Fear of Missing Out — o medo de estar perdendo o bonde). Pra te deixar ansioso, achando que está ficando pra trás, que está deixando produtividade na mesa, que todo mundo já migrou pro novo paradigma e você não. Ansiedade vende. Depois que você está inseguro, eles te cobram pra implementar algo de que você nunca precisou. FOMO é real — e aqui, é o modelo de negócio.

O modelo ainda é recorrente — repare na elegância. Primeiro te vendem a metodologia que gera artefatos — specs, grafos, boards, diagramas. Os artefatos se multiplicam, ninguém mais sabe onde está nada, e adivinha quem aparece? A mesma consultoria, agora vendendo a ferramenta que gerencia os artefatos, o curso que te ensina a gerenciar a ferramenta e o workshop de governança dos artefatos. É o vendedor de pá te parabenizando pelo buraco que você cavou — e te oferecendo uma pá maior.

A Gartner tem até nome oficial pra isso: “agent washing” — pegar produto existente, pendurar a etiqueta “agentic” e revender. A estimativa deles: só umas 130 das milhares de empresas que se vendem como “IA agêntica” são reais, e a previsão é de 40% dos projetos do tipo cancelados até o fim de 2027, por custo, valor incerto ou risco mal controlado. Aqui não tem implicância minha: é o ciclo do hype, medido, com previsão pública e tudo.

Da próxima vez que um influencer ou consultor tentar te empurrar esses produtos, faz uma pergunta simples: onde estão as suas dezenas de projetos open source de alta qualidade que ficaram melhores por causa dessas “técnicas”?

Eles não têm o que mostrar. Eu tenho — está tudo público, com código, benchmark e processo documentado. Quando a tecnologia vira commodity, o dinheiro migra pra taxonomia. Não seja o cliente dessa migração.

O padrão se repete em todos: eu esbarro numa pequena fricção do cotidiano, daquelas que a gente normalmente engole porque consertar custaria um fim de semana inteiro, e em vez de engolir eu abro um agente de IA e resolvo. O custo de transformar irritação em ferramenta despencou tanto que o cálculo inverteu. Hoje vale a pena consertar quase tudo.

Tudo que aparece abaixo está no meu GitHub, com binários, releases e instruções de instalação.

Nesse post: clock-tui (com os widgets google-calendar-tui e ghpending), github-visualize, frank_geary, frank_scanlation, frank_lyrics, frank_type, distrobox-gaming e aitrepreneur-docker.

clock-tui: um relógio de mesa que virou painel

O caso de uso é simples: eu tenho um monitor secundário vertical, e queria algo mais útil ali do que um wallpaper, alguma coisa que eu pudesse só bater o olho e ter informação relevante. Mas tudo começou porque eu só queria um relógio de mesa. Achei um programinha open source antigo de relógio em terminal, o clock-tui original, que estava parado havia tempos, e decidi fazer um fork e continuar o trabalho: o clock-tui.

Deixei ele mais bonito, modernizei as dependências de Rust, e a mudança mais importante: adicionei suporte a widgets de comando. O relógio fica no topo e embaixo entram painéis que rodam qualquer comando que imprima texto, cada um com refresh independente. Dois widgets que eu mesmo criei pra ele:

• google-calendar-tui: uma agenda read-only do Google Calendar no terminal, usando as contas que já estão no GNOME Online Accounts (zero configuração de OAuth). Bato o olho e sei meus compromissos do dia.
• ghpending: lista issues e pull requests abertos em todos os repositórios que eu acompanho. Agora que eu tenho dezenas de projetos open source, é assim que eu percebo em segundos quando chega PR ou issue nova, sem abrir o GitHub.

E hoje eu passei o dia adicionando suporte a temas, porque alguém no X comentou que o visual dava pra lembrar Evangelion. Desafio aceito: agora tem o tema evangelion (roxo e lavanda) e o tema nerv (vermelho, âmbar e verde, inspirado nas telas de alerta da série), alternando em runtime com Shift+T. O tema é injetado nos widgets via variável de ambiente, então os painéis acompanham a paleta.

Instalação no Arch: yay -S clock-tui-bin. Os widgets: yay -S ghpending-bin (também tem brew install via akitaonrails/tap no macOS) e yay -S google-calendar-tui-bin. Todos têm binários prontos nas releases do GitHub pra quem não usa Arch.

github-visualize: inútil, mas bonito

Esse nasceu por causa do artigo do Jarred Sumner sobre reescrever o TypeScript do Bun em Rust, sobre o qual eu postei recentemente. Não sei qual ferramenta ele usou pra ilustrar o post, mas eu gostei demais das animações dos gráficos. É inútil? É. Mas é bonito, e beleza é motivo suficiente pra fazer uma cópia.

O github-visualize é um dashboard self-hosted que monitora meus repositórios do GitHub e faz replay do progresso deles com visualizações animadas: timeline de commits com linhas adicionadas e deletadas em escala logarítmica, heat map de commits por dia e hora, corrida de CI até o verde. Agora eu adiciono qualquer repositório meu e tenho visualizações bonitas de produtividade, atividade, commits e builds. Talvez eu use em slides de apresentação, ou pra ilustrar posts futuros aqui no blog.

Instalação: imagem pública no Docker Hub como akitaonrails/github-visualize, container único com SQLite num volume, sem banco externo nem Redis.

Frank Geary: email do jeito que eu queria

Eu decidi usar o Geary, do GNOME, como meu cliente de email principal. É o que chega mais perto da interface do Mail padrão da Apple: limpo, direto, sem cerimônia. Eu sei, existe o Thunderbird, mas eu o acho inchado e muito feio. Existe o Mailspring, que eu acho inchado e pesado. Meu fluxo de email é curto: varrer a inbox, taggear, arquivar e responder. Nada além disso.

O Geary é quase perfeito, mas tinha dois problemas grandes pra mim. Primeiro: no meu monitor vertical, sobra muito menos espaço horizontal, e o Geary tem 3 colunas fixas. A primeira coluna, que só lista contas e pastas/tags, eu não preciso ver o tempo todo, mas não existia jeito de recolher.

Segundo, e mais grave: o campo de destinatário do compositor na prática não autocompletava nada (o Geary até tem o mecanismo, mas com um filtro de visibilidade de contatos tão restritivo que nunca sugeria ninguém). Eu tinha que digitar o endereço na mão ou copiar e colar de outro email. Em 2026.

Minha primeira solução foram dois módulos GTK externos injetados no Geary, um pra cada problema (ambos obsoletos agora). Funcionavam, mas exigiam instalar o Geary compilado do source, e a cada yay -Syu lá ia ele recompilar tudo de novo.

Cansei e fiz o que deveria ter feito desde o início: forkei o Geary e criei o Frank Geary, que adiciona as duas funcionalidades direto no código. A barra lateral agora recolhe, e o destinatário autocompleta consultando os contatos dos emails existentes. Vou manter o fork rebaseando do upstream com frequência.

E a melhor parte: agora tem pacote no AUR, então instalar é assim:

yay -S frank-geary-bin    # binário pronto (x86_64), da release do GitHub
yay -S frank-geary        # ou compilando do source

Os dois pacotes substituem o geary do sistema (fazem provide/conflict nele), então a troca é limpa e as atualizações chegam como qualquer outro pacote. Um detalhe depois de instalar ou atualizar: quando a opção de vigiar email novo está ligada, o Geary continua rodando em background como serviço D-Bus, então roda um geary --quit pra garantir que nenhum processo antigo ficou no ar.

Mangá em japonês: FrankYomik, FRANK MANGA+ e FRANK Scanlation

Quem acompanha o blog sabe do meu amor por mangá japonês. Eu já postei sobre o FrankYomik, que nasceu pra eu conseguir ler os mangás originais em japonês que eu compro na Amazon do Japão.

O problema: mangá voltado pra público adulto (não, não é pornô! estou falando de temas como negócios ou assuntos militares) não tem “furigana”, que são as legendinhas em kana impressas ao lado dos kanji difíceis, indicando a leitura. Mangá shounen tem furigana em tudo, então dá pra ler com vocabulário de estudante. Os adultos assumem que você já sabe ler os kanji raros. Eu não sei.

O FrankYomik resolve isso adicionando furigana em cima da página, em tempo real: um modelo detecta os balões de fala, o manga-ocr extrai o texto e o furigana (ou uma tradução completa, via LLM local no Ollama) é renderizado por cima, tudo rodando no meu próprio hardware. E o detalhe importante: on-the-fly, por cima da imagem que eu já tenho aberto legitimamente, sem baixar nem redistribuir página nenhuma, então sem infringir copyright ou licença.

Depois veio o FRANK MANGA+, sobre o qual eu também já postei. Eu pago a assinatura do Manga Plus, o app oficial da Shueisha, mas ele só deixa ler no celular (Android/iOS). Num tablet pequeno até vai, mas eu tenho um monitor Samsung Odyssey OLED de 32" parado na minha frente.

Descobri como usar a minha própria assinatura fora do app e construí um leitor desktop em Tauri: roda em Linux, macOS e Windows, o tier gratuito funciona direto e assinante cola o próprio secret pra liberar os capítulos premium.

Instalação: AppImage, .deb e .dmg nas releases, ou yay -S mangaplus-reader-bin no Arch.

E finalmente, eu também leio as eventuais “scanlations” da comunidade: fãs escaneiam as páginas do mangá original japonês e traduzem (hoje em dia a maioria usa IA no processo, existem até modelos treinados pra reconhecer os balões de fala, e eu usei um desses no próprio FrankYomik). Essas scanlations ficam espalhadas por vários sites diferentes, tipo o MangaDex.

Primeiro eu fiz uma extensão de Chrome pra embelezar esses sites (hoje obsoleta), mas cansei de viver com dezenas de abas no Brave só pra sites de scanlation. Então construí o FRANK Scanlation, na mesma linha do FRANK MANGA+: um app desktop que concentra todas as minhas scanlations favoritas num lugar só, com biblioteca, progresso de leitura por título e checagem de capítulos novos.

As janelas de leitura carregam o próprio site e injetam um leitor decente por cima, com spreads de página dupla e navegação por teclado. Nada é hardcoded pra site nenhum: são heurísticas que detectam sequências de imagens e numeração de capítulos em qualquer URL. Virou meu jeito preferido de ler os mangás que não existem pra comprar na Amazon nem na Shueisha.

Instalação: AppImage, .deb e .rpm (e build de macOS) nas releases do GitHub.

Frank Lyrics: decorando música linha por linha

Eu já postei sobre o Frank Karaoke, um appzinho pra adicionar pontuação em cima do YouTube e curtir karaokê com família e amigos. Mas tem um caso de uso irmão: eu gosto de aprender música nova (abertura de anime nova, por exemplo), e o processo de decorar letra é repetir a MESMA linha várias vezes. No player do YouTube isso é um inferno: fica caçando no dedo o ponto exato da timeline pra voltar, erra por dois segundos, volta demais, passa do ponto.

Pra resolver isso criei o Frank Lyrics, uma extensão de Chrome simples que descobre o timing correto de cada linha da letra usando os marcadores públicos do LRCLIB e injeta controles na própria página do YouTube. O LRCLIB, pra quem não conhece, é uma biblioteca aberta e comunitária de letras sincronizadas: cada linha vem com timestamp (o formato LRC clássico dos players de música), com API pública, gratuita e sem chave.

A extensão casa esses timestamps com o vídeo e me dá botões de repetir a linha exata que eu estou decorando, quantas vezes eu precisar, sem caçar timeline. Se você curte karaokê, o combo Frank Karaoke + Frank Lyrics deve te atender bem.

Instalação: baixa o .zip das releases, descompacta, abre chrome://extensions, liga o modo desenvolvedor e faz “Load unpacked” apontando pra pasta.

Frank Type: treino de digitação com prosa de verdade

Quem me acompanha há tempo sabe que eu amo meus teclados. Tem vídeos no canal Akitando sobre isso e posts aqui no blog sobre meus teclados favoritos. E de tempos em tempos eu gosto de treinar no MonkeyType. Mas eu não gosto de digitar palavras aleatórias. O TypeRacer resolve isso usando textos públicos de verdade, só que ele me obriga a esperar outros jogadores na sala (eu detesto jogos multiplayer). Ou seja: eu queria uma experiência single player, com prosa de verdade, mas com a estética do MonkeyType, que eu prefiro.

Então criei o Frank Type, um mini-clone dos dois: um treinador de digitação em Rails 8 que usa trechos normalizados de prosa em domínio público em vez de listas de palavras aleatórias. É local-first e sem cadastro: histórico de sessões, tempos e gráficos de perfil ficam no local storage do navegador. Tem até heat map de dígrafos pra mostrar quais combinações de teclas te atrasam.

Instalação: é um container Docker publicado como akitaonrails/frank_type. Um comando levanta em http://localhost:3200:

curl -fsSL https://raw.githubusercontent.com/akitaonrails/frank_type/master/bin/docker-run.sh | bash

distrobox-gaming: uma biblioteca de como instalar jogos no Linux

Eu jogo no mesmo PC em que trabalho, mas me recuso a misturar pacote de emulador e gambiarra de Wine com meu ambiente de desenvolvimento. A solução foi isolar os jogos inteiros dentro de um distrobox (containers que se integram ao desktop como se fossem nativos), e o distrobox-gaming é o repositório de playbooks Ansible que constrói essa box Arch do zero: ES-DE de frontend, emuladores standalone, cores do RetroArch, configs por jogo. Meu Arch/Omarchy host fica limpo.

A regra que eu me impus: todo jogo novo que eu instalo tem que virar receita Ansible reproduzível. Confesso que ainda não testei a reconstrução completa do zero, mas a ideia é essa: qualquer truque ou hack necessário fica documentado no código em vez de perdido no histórico do shell.

E truque é o que não falta, porque eu ando instalando abandonware antigo: a série Colin McRae Rally (da versão de PS1 com patch de 60 fps até o DiRT de 2007), Sega Rally Revo, OutRun 2006 Coast 2 Coast, entre outros. Cada um com suas manhas de Wine, seus patches e suas configurações. Sem querer, o repositório está virando uma biblioteca de documentação sobre como instalar jogos, emuladores e retro games no Linux.

Na mesma linha existe o distrobox-llm, que faz o mesmo isolamento pro meu ambiente de LLMs locais (CUDA, Ollama, LM Studio e companhia), deixando só o driver NVIDIA no host.

Instalação: clona o repositório e roda os playbooks:

cd ansible
ansible-galaxy collection install -r collections/requirements.yml
cp host_vars/localhost.yml.example host_vars/localhost.yml
$EDITOR host_vars/localhost.yml
ansible-playbook site.yml

aitrepreneur-docker: ComfyUI sem sujar o sistema

Pra geração de imagens eu gosto do ComfyUI, e postei sobre ele ano passado. Eu acompanho um youtuber chamado Aitrepreneur que mantém uma página no Patreon com receitas pra instalar e configurar o ComfyUI com os modelos e workflows mais recentes. O trabalho de curadoria dele é ótimo, mas as receitas são scripts .sh old school, pensados pra rodar one-shot numa instância do RunPod, por exemplo.

Agora que as LLMs evoluíram a ponto de escreverem Dockerfiles decentes, criei o aitrepreneur-docker, que converte esses scripts em imagens e containers Docker de verdade: versões pinadas, dados persistentes no host ou NAS, um comando pra subir ou atualizar cada app. Assim eu rodo tudo isolado na minha máquina, sem entulhar meu Linux com toneladas de pacotes Python e gambiarras que poderiam desestabilizar o sistema.

Dois avisos importantes. O crédito da seleção de stack, curadoria de modelos e workflows é todo do Aitrepreneur: o repositório só traduz o trabalho dele pra forma de Docker, e os scripts originais dele são conteúdo pago do Patreon que NÃO está incluído.

Se achar útil, assine o Patreon dele pra contribuir com a criação de conteúdo (é lá que você pega os arquivos originais). E o repositório não cobre tudo que ele já produziu, só as receitas mais recentes.

Instalação: git clone, make setup (cria o .env pra você colocar seu token da Hugging Face), make build e make up.

E tem mais de onde vieram esses

Se você é novo por aqui: isso é só a leva que ainda não tinha aparecido no blog. Tem muito mais projeto que eu já cobri em posts dedicados. O ai-memory é o mais popular, mais usado e com mais contribuições de todos. O ai-jail, que apareceu de novo no post de ontem sobre agentes destrutivos, foi o primeiro da série e é o segundo mais popular.

E tem os outros da série Frank (“Frank” em homenagem ao Frank Rosenblatt, criador do perceptron, a rede neural original; o nome marca os projetos experimentais que eu faço por diversão):

• Frank Sherlock: indexador inteligente de imagens
• Frank Mega: clone do MEGA pro meu home server
• FrankMD: editor de markdown
• Frank FBI: analisador de fraudes por email
• Frank Investigator: ensina a questionar notícias

Tudo é open source e está no meu GitHub. Todo mundo é bem-vindo pra contribuir com issues, pull requests, ou simplesmente compartilhando com os amigos. Cada um desses projetos nasceu de um probleminha real meu. Vai que um deles resolve o seu também.

Nos últimos meses começaram a aparecer histórias de empresas grandes gastando quantidades absurdas de tokens em ferramentas de IA sem conseguir apontar, com clareza, o resultado equivalente em produto. O caso que ficou mais famoso foi a Uber queimando o orçamento anual de IA em poucos meses com uso pesado de ferramentas como Claude Code, e executivos admitindo que ainda não conseguiam traçar uma linha reta entre consumo de tokens e valor entregue. Não é que ninguém tenha usado. Usaram demais. Esse é justamente o problema.

Até aqui, acho que a maioria já entendeu que prompt de uma linha não resolve nada. Aquela fantasia de escrever “faça um clone do Uber” e voltar com um produto pronto morreu rápido. A resposta do mercado foi correr para outro lado: spec-driven development.

Em vez de pedir tudo em uma frase, você escreve uma especificação. Define escopo, casos de uso, critérios de aceite, arquitetura desejada, restrições, fluxos, talvez até um PRD inteiro. Depois entrega isso para o agente e espera que ele implemente com menos ambiguidade.

Isso é melhor do que one-shot? Claro. Mas ainda acho que está errado.

O problema não é falta de especificação

Eu venho martelando essa ideia há anos, antes de LLM virar moda. Dois vídeos meus são importantes pra entender o ponto: Não Terceirize Suas Decisões e Esqueça Metodologias Ágeis.

O resumo é simples: a maioria dos profissionais foi treinada a não decidir.

Pensa no seu dia a dia. Muita gente não faz nada se não houver backlog pronto. Cruza os braços, culpa gestão, culpa colega, culpa cliente, e espera alguém dizer o que fazer. Quando a tarefa chega, executa. Quando dá errado, a culpa era do requisito. Quando o cliente reclama, a culpa era da prioridade. Quando o produto degrada, a culpa era do processo.

Quase ninguém decide de verdade, banca a decisão até o fim e sofre as consequências. E sem sofrer a consequência, você não aprende a decidir.

Você não aprende quais escolhas levam a quais resultados. Não aprende a priorizar. Não aprende a explicar por que algo precisa existir. Não aprende a escrever uma especificação porque entende o problema; aprende a preencher template para ninguém reclamar.

O Agile virou burocracia estruturada

Os princípios originais de 2001 foram triturados. O que muita empresa chama de Agile hoje é burocracia estruturada em ciclos menores.

O desenho clássico todo mundo já viu: backlog, sprint planning, sprint, daily, review, retrospective, próximo sprint. A Scrum Guide descreve os eventos formais. Diagramas como o Scrum process da Wikimedia mostram o círculo bonitinho. Na prática, muita equipe transformou isso em teatro.

Passa-se um dia inteiro debatendo o que entra no backlog. E o backlog final raramente é o que precisa ser feito. É o consenso de menor resistência. Compromisso em cima de compromisso. Pequenas tarefas, pequenos riscos, pequenas vitórias, pequenos fracassos. Tudo desenhado para não gerar conflito demais.

Isso não é apenas medíocre. É pior: é a escolha ativa por decisões fáceis, que não levantam muita crítica contra você.

Depois a equipe passa dias ou semanas implementando aquele backlog morno. O QA entra, encontra problemas, tenta encaixar correções na próxima rodada. Mais alguns dias, talvez mais duas semanas. Um mês depois, talvez dois, a decisão original finalmente começa a mostrar resultado em produção.

Só que o resultado está tão longe da decisão que quase ninguém faz a correlação. A equipe não sente o peso real do que decidiu. O erro não vira aprendizado. O processo não melhora. A parte mais importante de qualquer sistema de melhoria contínua, o kaizen, nunca acontece.

O que acontece é outra coisa: todo mundo aprende a ficar invisível.

Você aprende a agradar gestão, não o produto. Aprende a reduzir atrito, não a resolver o problema. Aprende a sobreviver à reunião, não a entregar valor. E quando os resultados pioram, a resposta da alta gestão é previsível: mais controle, mais regra, mais gate, mais comitê, mais checklist. A engrenagem fica mais pesada. O time fica mais covarde.

Então chega a IA

Agora entra a LLM.

Até pouco tempo atrás, o maior gargalo de desenvolvimento era escrever e ajustar código. Codar levava dias ou semanas. Por isso tanto esforço era colocado na fase de planejamento. Se o time vai gastar duas semanas implementando, parece fazer sentido gastar um dia discutindo o que entra na sprint.

Mas ferramentas de coding com LLM mudam a posição do gargalo. Elas conseguem fazer uma parte grande do trabalho braçal: gerar estrutura, escrever testes básicos, fazer refactors, adaptar APIs, criar telas, preencher boilerplate, tentar correções. Não é perfeito, mas é rápido o bastante para mudar a economia do processo.

É aquela história da corrente e do elo mais fraco. Você reforça um elo, outro passa a limitar o sistema. Antes, o elo fraco era a velocidade de codificação. Agora, cada vez mais, é a capacidade humana de decidir, explicar, testar e revisar.

O erro das empresas é colocar LLM dentro do mesmo processo quebrado e esperar ganho multiplicativo.

Você pega pessoas treinadas por anos a não decidir, entrega uma ferramenta que exige clareza de decisão, e se surpreende quando sai lixo mais rápido.

A LLM reflete o usuário

Um agente de coding precisa que você explique o objetivo, o contexto, as restrições, as prioridades, o que não pode quebrar, quais caminhos são aceitáveis, como medir sucesso. Ele precisa de uma direção objetiva.

Agora vai entrevistar seu time. Pergunta para cada pessoa:

• qual é o objetivo real do que você está fazendo?
• como isso melhora o produto?
• qual métrica deveria mudar?
• que trade-off você está aceitando?
• o que não pode quebrar?
• quais casos tristes precisam ser testados?

Muita gente não sabe responder. Sabe qual ticket pegou. Sabe que precisa fechar algumas tarefas por semana. Sabe que tem daily amanhã. Mas não sabe por que aquilo importa.

E aí você entrega uma LLM para essa pessoa.

O resultado não é mágica. É espelho. Código ruim dez vezes mais rápido. Bug dez vezes mais rápido. Cliente irritado dez vezes mais rápido. Pull request gigante dez vezes mais rápido. O problema não é só a IA. É que a IA amplifica a falta de direção.

Spec-driven development tenta corrigir isso com documentação. Mas se a especificação nasce do mesmo processo covarde, ela só documenta a covardia. Um PRD escrito por quem não entende a decisão continua ruim. Critério de aceite escrito para evitar conflito continua desviando do problema real. O agente só vai executar melhor uma decisão ruim.

O processo precisa mudar

Minha hipótese é que o processo inteiro precisa ser redesenhado ao redor da nova restrição. De novo: é especulação. Eu não tenho dados suficientes para provar isso. Mas, olhando para o tipo de falha que vejo em empresas e para o tipo de sucesso que vejo em uso individual intenso, minha teoria é essa:

jogue fora o ritual de sprint como unidade central de trabalho.

Não faz sentido manter dias de planning, dias de review e semanas de codificação como se o gargalo ainda fosse o mesmo. Com LLM, o ciclo precisa ficar mais curto. Muito mais curto. Idealmente, dentro do mesmo dia.

No meu desenho ideal, cada programador com LLM deveria parear diretamente com um Product Owner por blocos de trabalho curtos. O papel do PO é fechar a lacuna que o programador normalmente tem: objetivo, prioridade, restrição, contexto de negócio, resultado esperado. Isso precisa entrar no prompt e na conversa com o agente.

Mas como codar deixou de ser o gargalo principal, o PO não precisa esperar duas semanas para ver resultado. Ele pode sentar com o programador durante uma manhã, implementar uma pequena fatia funcional, ajustar na hora, decidir na hora, cortar escopo na hora. Depois roda para outro programador.

Em seguida, entra QA. Não como uma fase distante, mas como pareamento no mesmo ciclo. O QA fecha outra lacuna comum do programador: testar só o caminho feliz, esquecer casos de erro, não automatizar o suficiente, não pensar em regressão de comportamento. A função do QA vira ajudar a transformar a implementação em algo verificável agora, enquanto o contexto ainda está quente.

Depois entra o Tech Lead. Também no mesmo dia, não duas semanas depois. Ele olha para o que mudou e fecha a terceira lacuna: complexidade desnecessária, design ruim, regressão escondida, documentação faltando, vulnerabilidade óbvia, performance piorando, acoplamento que nasceu sem necessidade.

Constrói, checa, ajusta. Tudo em tempo real.

O novo papel de cada pessoa

Esse modelo cobra mais responsabilidade, não menos.

O programador deixa de ser a pessoa que só pega ticket. Ele precisa aprender a transformar objetivo em instrução executável. Precisa discutir trade-off. Precisa entender por que está codando. Precisa usar a LLM como ferramenta de execução e investigação, não como desculpa para desligar o cérebro.

O PO deixa de ser fábrica de backlog. Ele precisa decidir com o programador, olhando para o produto vivo. Não é escrever card e sumir. É ver a coisa nascer, ajustar, cortar, priorizar e aceitar consequência.

O QA deixa de ser a pessoa que recebe o pacote no fim e devolve defeito. Ele entra cedo para transformar comportamento esperado em verificação. Se a LLM acelera código, QA precisa acelerar aprendizado sobre risco.

O Tech Lead deixa de ser carimbo de PR atrasado. Ele entra enquanto ainda dá para mudar barato. Ajuda a manter simplicidade, remove complexidade, protege arquitetura, documentação, segurança e performance.

Nada disso funciona se todo mundo continuar usando IA como autocomplete caro dentro do mesmo Scrum burocrático.

Por que empresas não vão gostar disso

Porque esse processo expõe decisões.

No processo atual, a decisão se dilui. Foi o backlog. Foi o PO. Foi o refinamento. Foi a sprint. Foi o time. Foi a dependência. Foi o cliente que mudou de ideia. Todo mundo consegue se esconder.

Num ciclo curto com LLM, a decisão aparece rápido. Você disse que aquilo era prioridade? Então implementa agora. Você disse que o critério de aceite era esse? Então testa agora. Você disse que esse design era bom? Então revisa agora. Se estiver errado, a consequência aparece no mesmo dia.

Isso é desconfortável. Mas é assim que se aprende.

Sem consequência próxima, decisão vira teatro. Com consequência próxima, decisão vira treino.

Como implementar isso sem queimar dinheiro

O primeiro passo é aceitar uma coisa que programador profissional costuma odiar: dá para jogar código fora.

Na verdade, você deveria jogar código fora com muito mais frequência.

Código não é monumento. Código é material de trabalho. Deletar código é tão importante quanto escrever código novo. É por isso que usamos Git. A ideia sempre foi trabalhar em branches, experimentar caminhos, mudar de ideia, comparar alternativas, apagar o que não funcionou e manter só o que sobreviveu ao teste da realidade.

Só que, no processo tradicional, código fica caro demais emocionalmente. Se levou duas semanas para sair, ninguém quer admitir que foi desperdício. O gerente sente que apagar aquilo prova que a decisão anterior foi ruim. O programador defende a implementação porque sofreu para fazê-la. O time empurra o problema para frente porque deletar parece derrota. Não é. Às vezes é higiene.

Com LLM, esse custo muda. Fica barato errar. Fica barato prototipar. Fica barato fazer prova de conceito. Fica barato testar dois caminhos e jogar um fora. Fica barato pedir para o agente reescrever uma abordagem inteira numa branch temporária, comparar, documentar o aprendizado e dar git reset sem drama.

Então faça mais disso. Mais protótipos. Mais provas de conceito. Mais testes A/B internos. Mais branches descartáveis. Menos apego ao primeiro código que apareceu. LLM é muito boa nesse tipo de trabalho: explorar alternativas rápido, mostrar onde a especificação estava vaga e produzir material que você pode destruir sem culpa.

Mas não espere que todo mundo receba tokens de LLM numa segunda-feira e saiba fazer isso sozinho. Esse é o jeito mais rápido de queimar orçamento e depois dizer que IA não funciona.

Minha sugestão é o contrário: assuma uma ou duas semanas sem entrega planejada. Diga claramente que o objetivo não é produzir feature. É treinar o novo processo. Quebrar o ritual antigo. Deixar o time praticar em ambiente seguro. Se der errado, ótimo: reseta a branch, apaga o protótipo, documenta o que aprendeu e tenta de novo.

Nessa fase, o PO não deveria escrever especificação de vinte páginas. Deveria parear com o programador e construir prompts pequenos, um passo de cada vez, vendo o resultado em tempo real. A cada resposta da LLM, o PO aprende quanto detalhe o código realmente precisa. O programador aprende a perguntar melhor. QA aprende a transformar comportamento em teste cedo. Tech Lead aprende a cortar complexidade enquanto ela ainda é barata.

É assim que se adota LLM com alguma chance de dar certo: como mudança de processo, não como licença cara de autocomplete.

A conclusão incômoda

LLMs falham tanto porque elas entram em processos feitos por pessoas que foram treinadas a não decidir.

Não é só falta de prompt melhor. Não é só falta de spec maior. Não é só falta de governança de token. Tudo isso ajuda, mas não toca o centro do problema.

O centro é que muita gente não sabe explicar objetivo mensurável, não sabe priorizar, não sabe assumir trade-off, não sabe conectar decisão com resultado. E uma LLM precisa exatamente disso para ser útil.

Se você coloca IA no processo velho, você acelera o processo velho. Mais backlog medíocre. Mais decisão ruim. Mais bug. Mais custo. Mais rework. Mais relatório tentando provar produtividade que o cliente nunca sentiu.

Se você quer que LLM funcione, precisa redesenhar o processo ao redor dela. Ciclos menores. Pareamento real. Decisão perto da execução. Teste perto da decisão. Revisão perto do código. Resultado perto de quem decidiu.

Essa é a parte que programador precisa encarar: sim, você provavelmente nunca aprendeu a decidir direito. Nunca aprendeu a descrever objetivo de forma objetiva. Nunca aprendeu a medir consequência. O processo te treinou para isso. E agora a IA está revelando a falha.

O lado bom é que também dá para treinar o contrário.

Mas não vai acontecer com mais uma cerimônia, mais uma planilha de prompt, mais uma política de uso de IA, ou mais uma sprint cheia de tickets escritos para ninguém ser criticado.

Vai acontecer quando você parar de terceirizar decisão.

Em vez de fazer um demo de 1 dia e arriscar um “eu acho que sim”, resolvi ir all-in: mais de 500 horas, quase meio milhão de linhas de código e documentação, 24 repositórios entre públicos e privados.

Mas hoje me chamaram atenção pra um ponto que eu não imaginei que fosse gerar dúvida:

“Todos os 24 projetos são perfeitos, modelos de excelência de código?” — ABSOLUTAMENTE NÃO.

Achei que isso fosse óbvio. Pra começo de conversa, se eu achasse que qualquer um deles fosse tão bom assim, já estaria abrindo uma startup em cima. Não me falta recurso pra investir. Se não estou fazendo isso, obviamente é tudo em ritmo de hobby.

Segundo ponto óbvio: se eu pulo de um projeto pra outro em poucos dias, é porque perdi o interesse. Se gostasse muito, estaria ajustando até hoje. Sempre falei nos vídeos: software nunca “acaba”. Quando para, morre.

O objetivo era testar tipos diferentes de projetos pra ver como as LLMs se saíam em cada caso. Por isso tem projeto em Ruby on Rails, Rust, Go, Python, Crystal. Mais frameworks como Tauri e Flutter. Eu achava, por exemplo, que Flutter sendo bem popular, as LLMs não teriam muito trabalho. Tiveram. Conseguem avançar, só não tão suave quanto em Rails. Tauri foi “ruim” também. Crystal foi BEM ruim.

Terceiro ponto: todo projeto experimental virou “Frank”. Sarcasmo, claro. Não tenho paciência pra inventar nome bonito num projeto que sei de antemão que vai ser one-off.

Eu uso meu GitHub basicamente como repositório de exercícios e experimentos. Olhem todos os repos do passado: quase nenhum é “projeto” de verdade que eu queira manter. Faço o que eu prego nos vídeos: pra aprender, exercite-se em MUITOS projetos, mesmo que a maioria seja pra JOGAR FORA. Ninguém aprende tentando fazer um único projeto perfeito. Veja meus vídeos A Dor de Aprender ou o Guia Definitivo de Aprendendo a Aprender.

No meio de vários projetos meia-boca, alguns emergem naturalmente como os que eu gosto e mantenho. Na prática joguei todos contra a parede pra ver quais grudam. Os melhores naturalmente atraíram mais contribuidores também. Não fico vendo Issues e PRs todos os dias. Vejo uma vez por semana. Há uns dois ou três dias dei uma passada e fechei tudo que estava pendente, por exemplo. Mesmo nos projetos que não gosto tanto, se chega PR, eu reviso e aceito. Não foi útil pra mim, mas pode ser útil pra outra pessoa.

O ranking dos projetos

Pra ficar claro, segue um ranking dos projetos com comentário em cada um. As contagens de PR abaixo são não-dependabot (bump de gem não conta). A nota é minha estimativa de “quão estável e usável isso está no estado atual”.

Tier de cima (7-8/10)

ai-jail — 8/10. O único que está bem próximo de uma release estável 1.0. Foi o que teve mais tração: 19 PRs fechadas, 23 Issues resolvidas. Recomendo usar, funciona muito bem.

akitando-news (the M.Akita Chronicles) — 8/10. Foi o que fiz com mais cuidado, no modo “Agile Vibe Coding” que descrevi alguns posts atrás. E é o que eu mexo com mais frequência. Sempre tem coisinha pra ajustar, coisas que vou colocando, tirando, experimentando. Tanto que está funcionando toda semana. Por isso também: é fechado e não pretendo abrir.

akitaonrails.github.io — 7/10. É este blog. Mexo com frequência e já fechei umas 7 Issues e 30 PRs de contribuidores. Continuo ajustando aos poucos.

FrankMD — 7/10. Foi um dos primeiros que fiz, sem critério nenhum: só queria um editor que tivesse upload automático de imagem pro meu S3. Hoje uso Claude Code pra editar os posts, então só quem contribui é quem usa. Esse teve bastante tração, fechei 17 PRs e 29 Issues. Não é perfeito, mas está bom pra usar, pelo menos foi testado o suficiente.

easy-ffmpeg — 7/10. Projetinho pequeno, mas esse eu uso de fato nos vídeos. Meu OBS sempre grava em MKV e, quando quero compartilhar, converto pra MP4. Casos de uso pequenos assim. Está bom o suficiente pra usar.

Tier do meio (5/10)

distrobox-gaming — 5/10. É o mais recente, serve como “dump” de documentação dos meus retrogames. Uso como bloco de anotações e tem funcionado bem pro meu setup. Não estou preocupado que funcione pra mais ninguém. Quem quiser, manda PR.

llm-coding-benchmark — 5/10. Esse projeto não roda sozinho. Eu mando o Claude Code executar ele. O objetivo é tabular dados pra escrever os artigos sobre LLMs novas. O código deve estar BEM ruim.

FrankMega — 5/10. É o mais próximo de um exercício “todo list”. Eu só precisava compartilhar um arquivo grande com um amigo e pensei “hum, aposto que dá pra fazer um mini-mega em 1 dia”. Foi isso. O nome é brincadeira, de jeito nenhum chega perto do Mega de verdade, óbvio.

distrobox-llm — 5/10. Mais organização pessoal do meu PC: queria separar as ferramentas de IA num distrobox pra não ficar atualizando pacote grande toda hora.

Tier de baixo (3-4/10)

FrankYomik — 4/10. Essa era uma ideia na minha cabeça há anos. Só queria ver se o conceito funcionava. Funciona. Mas rodar LLMs locais pra isso é lento e não tão prático quanto eu gostaria. É o único que ainda devo voltar pra mexer mais, porque realmente quero usar. No estado atual, está em “funciona, mais ou menos”.

NW-Omarchy — 4/10. Outro experimento de “será que dá?”, que durou 2 dias. O conceito funcionou, mas não pretendo fazer muito mais que isso. Fica pra quem tiver interesse de continuar. Na prática eu quis testar se em X11 ficaria MUITO mais ruim que em Wayland. O gap é menor do que eu esperava, mas realmente não me vejo usando no dia a dia. Como já falei, pro nicho de pessoas que não tem como usar Wayland, é uma boa alternativa.

frank_investigator — 3/10. Comecei, mas não tive saco pra continuar. Plantei as sementes da ideia. Se ninguém mandar PR, vai evoluir pouco. Precisa de mais pesquisa e muito mais teste.

frank_fbi — 3/10. Mais um que quis testar o conceito, sem uso pessoal — nunca caí em phishing. Não sei pra onde levaria isso ainda.

frank_karaoke — 3/10. Nasceu de uma conversa de fim de semana com meus irmãos. Mais uma tentativa de usar Flutter (e ver como tem limitação tanto no Flutter quanto nas LLMs usando Flutter). Serviu pra eu aprender sobre o ecossistema de karaokê e descobrir que pontuação de verdade só com metadado específico por música. Então não avancei muito além de brinquedo.

Fundo do poço (1-2/10)

FrankSherlock — 2/10. Eu mesmo não uso. Por isso deve estar cheio de bug que precisa de correção. Foi teste pra ver se dava pra fazer um app Tauri, mas perdi o interesse rápido. Ainda dá pra melhorar, mas precisa de muito mais horas de uso, testes e correções. Foi a primeira vez que usei Tauri, então essa parte deve estar bem ruim também.

FrankClaw — 1/10. Eu mesmo não uso, e esse é o único que eu nem rodei uma única vez. O exercício foi só ver a dificuldade de traduzir o openclaw original de TypeScript pra Rust. Mas, como já postei várias vezes, não vejo utilidade no openclaw pra mim. Quando terminei a versão 0.1, parei. Ainda assim teve 6 PRs que fechei. Se alguém estiver interessado, pode contribuir.

shadPS4 — 1/10. Apesar de ter gerado muito código e muita documentação, nada foi pensado em virar contribuição. Foi exclusivamente aprendizado e pra resolver um problema muito específico. Deixei aberto pra mostrar como código puramente de material de estudo se parece.

easy-subtitle — 1/10. Comecei, perdi o interesse, nunca parei pra testar de verdade. Só dei push e esqueci.

Os privados

Além do akitando-news, tenho no meu Gitea privado coisas como my-omarchy-config, emulators-reorg-2026, thinkpad-omarchy-config, homelab-docs, akitando_english_translation etc. Não vou descrever porque vocês nunca vão ver. Servem como “scratchpads” pro Claude Code administrar minhas máquinas.

O que esse ranking diz

Notem: não tem nenhum projeto que eu fiz que considero 10/10.

Pra um projeto sair de hobby e virar projeto de verdade, precisa de usuários e feedback. Se ninguém usa, sempre vai ter dezenas de bug funcional que nunca vai ser corrigido, porque ninguém esbarrou neles. Projeto sem usuário está morto.

Por isso eu repito nos vídeos: não existe planejar em detalhes, escrever um monte de código, e uma hora “terminar”. Não. Quando você acha que “terminou”, na verdade é a versão 0.1. Aí começam os meses de experimentação com usuário real reportando bug. Sair corrigindo. Dessas correções saem refatoramentos, mudanças de arquitetura porque as premissas iniciais estavam erradas comparado ao uso real. Software NUNCA acaba.

O resumo do aprendizado dessa maratona

16 horas por dia, todos os dias, vibe coding, sempre vai sair com slop. Não tem jeito. Não adianta forçar quantidade. Tem que revisar manualmente, commit a commit, PR a PR. Por que eu não fiz isso em todos? Simples: não estou sendo pago. Fiz em uns 2 ou 3 projetos. O resto eu só queria testar o conceito e seguir pro próximo.

A forma correta é o que reportei vários posts atrás: “Agile” Vibe Coding. É meu jeito sarcástico de dizer “use XP e técnicas normais de engenharia de software”. Métricas, monitoramento, CI, etc. etc. Nada disso mudou. Sem isso, vai acabar como vários dos meus exercícios: one-off pra jogar fora.

Não tenha vergonha de subir projeto “ruim”. O que eu não pensei é que tem gente que assume que, só porque subi código, eu acho que é perfeito. Mas isso é o que essas pessoas fazem: acham que só vale a pena subir código bem feito, por isso nunca sobem nada. Eu já disse VÁRIAS vezes e demonstro: não ligo pro meu código, não tenho apreço pelo meu código, GitHub é diretório temporário de dump de qualquer coisa. Os que eu realmente gosto, normalmente estão privados.

Projeto realmente bom não basta “dizer” que é bom. Coloque seu dinheiro onde está sua boca: abra um negócio em cima, cobre dos usuários, entregue qualidade. Eu estou aposentado, não preciso cobrar nada, mas também não tenho vontade de trabalhar de graça. No momento que o código parou de me divertir, eu abandono e pulo pro próximo. Os que me interessaram mais (ai-jail, M.Akita Chronicles) continuo com mais frequência. Simples assim.

Como eu esperava, e como mostrei tanto nesses projetinhos quanto no benchmark, a escolha é simples: use GPT Codex ou Claude Code num dos planos subsidiados. Não pague por token. É onde está a produtividade 5x (máximo 10x, com slop junto). Sim, tem Kimi v2.6 ou DeepSeek V4 Pro. Mas adianto: os projetinhos abaixo de nota 5 virariam projetinhos abaixo de nota 2 com eles.

O ponto que mais importa

IA não substitui um bom programador. IA reflete e acelera quem você é. Se é um bom programador, a IA acelera bom código. Se é um mau programador, a IA acelera mau código.

Foi exatamente o que eu mostrei: a maior parte dos projetos que eu fiz eram one-off e teste de conceito. Mau código, sem interesse de continuar. A IA acelerou eu terminar esses testes de forma meia-boca. Pra mim está ótimo: sem a IA eu nem teria começado. Agora que vi como fica, posso riscar da minha lista e seguir em frente.

O que importa é qual é seu OBJETIVO. Se for fazer um negócio e cobrar de gente, tem que ter 10x mais cuidado do que eu tive. Tudo que eu faço é pra jogar fora. Não preciso ganhar dinheiro com nenhum desses projetos. Não assumam coisa que eu nunca falei.

O Problema: Legendas

Quem mantém uma coleção de filmes e séries sabe a dor. Você baixa o arquivo MKV, mas a legenda embutida está dessincronizada. Ou pior: não tem legenda nenhuma no idioma que você quer. Aí você vai no OpenSubtitles, baixa uma legenda, e ela tá 3 segundos adiantada porque foi feita pra outro release. O fluxo manual é:

1. Extrair tracks de legenda do MKV com mkvextract
2. Ir no OpenSubtitles, procurar legenda pro filme
3. Baixar, testar, ver que tá fora de sync
4. Rodar algum tool de sync (ffsubsync, alass)
5. Renomear o arquivo, mover pro lugar certo
6. Repetir pra cada idioma, pra cada filme

Pra quem tem 10 filmes, é tolerável. Pra quem tem centenas, é insano. É exatamente o tipo de coisa que deveria ser automatizada.

Subservient: A Solução Python

Pesquisando o que já existia, encontrei o Subservient. É um projeto Python que automatiza exatamente esse fluxo: extrai legendas de MKVs, baixa do OpenSubtitles via API REST, sincroniza com ffsubsync, e limpa propagandas dos arquivos SRT.

O projeto é completo. Tem modo filme e modo série, smart sync (testa todos os candidatos em paralelo e pega o melhor) e first-match (para no primeiro que funcionar). Usa o hash do OpenSubtitles pra matching exato e limpa watermarks e propagandas com mais de 30 regex patterns.

Mas tem os problemas típicos de distribuição Python:

• 7 dependências pip: colorama, requests, langdetect, ffsubsync, platformdirs, pycountry, tqdm
• ffsubsync como engine de sync: que por sua vez depende de numpy, auditok, e mais um monte de pacote Python
• Interface interativa com menus: boa pra uso manual, péssima pra scriptabilidade
• Config em formato INI: não é o fim do mundo, mas YAML é mais ergonômico
• 10.220 linhas em 6 arquivos Python: arquivos de 2.700 linhas com funções de centenas de linhas cada

O ponto não é que Python seja ruim pra isso. O Subservient funciona. Mas instalar e manter em produção é outra história. Se você quer rodar num server headless, precisa de Python 3.8+, pip, virtualenv (ou vai poluir o sistema), e torcer pra nenhuma dependência quebrar com a próxima atualização do OS.

O Experimento: Port pra Crystal com Claude

Aqui é onde a coisa fica interessante. Eu queria testar uma hipótese: o Claude consegue pegar um projeto open source grande, entender a arquitetura, e fazer um port completo pra outra linguagem?

Não estou falando de traduzir arquivo por arquivo. Estou falando de entender o que o projeto faz, redesenhar a arquitetura onde faz sentido, e gerar código idiomático em Crystal.

O que eu fiz:

1. Pedi pro Claude clonar e analisar o repositório do Subservient
2. Expliquei as decisões de design: usar alass (binário Rust, sem dependências Python) no lugar do ffsubsync, subcomandos CLI ao invés de menus interativos, YAML ao invés de INI
3. Pedi port feature-parity, com testes

O alass é um detalhe importante. O ffsubsync funciona bem, mas é um pacote Python que puxa numpy e faz análise de áudio. O alass faz a mesma coisa (sincronização de legendas por análise de timing), mas é um binário Rust standalone. Trocar um pelo outro elimina a maior dependência Python do stack.

O Resultado: easy-subtitle

Cinco commits. Menos de 40 minutos do primeiro ao último.

O primeiro commit já entrega o projeto funcional: 8 comandos CLI, cliente OpenSubtitles com rate limiting, 76 testes passando, GitHub Actions com CI e release pra Linux e macOS.

Números

A diferença de LOC é gritante: 10.220 vs 2.516. Mas isso não é mérito só do Crystal. O Python original tem arquivos monolíticos de milhares de linhas, com muita duplicação e lógica de UI misturada com lógica de negócio. O port separa as responsabilidades em módulos pequenos e focados.

Arquitetura do Port

easy-subtitle/
  src/easy_subtitle/
    cli/           # Router + 9 comandos (init, extract, download, sync, run, clean, scan, hash, doctor)
    core/          # Mapa de idiomas, parser/writer/cleaner de SRT, scanner de vídeo
    acquisition/   # Cliente API OpenSubtitles, auth, busca, download, movie hash
    extraction/    # Parsing de tracks MKV, extração, remuxing
    synchronization/  # Runner do alass, cálculo de offset, estratégias smart/first-match
    models/        # VideoFile, SubtitleCandidate, CoverageEntry

Cada módulo tem uma responsabilidade clara. O maior arquivo tem 144 linhas (config). No Python original, o acquisition.py sozinho tem 2.726 linhas.

O Que Cada Comando Faz

# Gerar config padrão
easy-subtitle init

# Extrair legendas de dentro de MKVs
easy-subtitle extract /path/to/movies

# Baixar legendas do OpenSubtitles
easy-subtitle download -l en,pt /path/to/movies

# Sincronizar legendas baixadas com o vídeo
easy-subtitle sync /path/to/movies

# Pipeline completo: extract → download → sync
easy-subtitle run /path/to/movies

# Limpar propagandas/watermarks de SRTs
easy-subtitle clean /path/to/subtitles

# Ver cobertura de legendas por idioma
easy-subtitle scan --json /path/to/movies

# Computar hash OpenSubtitles (debug)
easy-subtitle hash /path/to/movie.mkv

# Validar setup: config, credenciais, dependências
easy-subtitle doctor

O doctor é um comando que eu adicionei depois. Ele verifica se o config existe, se a API key está configurada, testa login na API, e checa se mkvmerge, mkvextract e alass estão no PATH. Mostra instruções de instalação específicas pro OS quando algo falta.

Smart Sync com Fibers

O smart sync é a parte que eu mais gostei de ver o port. No Python original, ele usa ThreadPoolExecutor pra rodar múltiplos candidatos em paralelo. Em Crystal, a mesma lógica fica mais natural com fibers e channels:

def execute(candidates : Array(Path), video : VideoFile) : SyncResult?
  channel = Channel(SyncResult).new(candidates.size)

  candidates.each do |candidate|
    spawn do
      result = sync_one(candidate, video)
      channel.send(result)
    end
  end

  results = Array(SyncResult).new(candidates.size)
  candidates.size.times do
    results << channel.receive
  end

  accepted = results.select(&.accepted?)
  accepted.min_by(&.offset)
end

Cada candidato de legenda é sincronizado em um fiber separado (via spawn). Os resultados voltam pelo Channel. No final, pega o aceito com menor offset. Sem ThreadPoolExecutor, sem futures, sem callbacks.

Rate Limiting da API

O OpenSubtitles exige throttling de 500ms entre requests. O cliente Crystal implementa isso com Mutex:

RATE_LIMIT_MS = 500

private def throttle! : Nil
  @mutex.synchronize do
    elapsed = Time.utc - @last_request_at
    remaining = RATE_LIMIT_MS - elapsed.total_milliseconds
    sleep(remaining.milliseconds) if remaining > 0
    @last_request_at = Time.utc
  end
end

Simples, thread-safe, sem biblioteca externa.

Instalação

O binário estático sai do GitHub Actions e pode ser instalado de três formas:

# Homebrew (macOS / Linux)
brew install akitaonrails/tap/easy-subtitle

# Script de instalação
curl -fsSL https://raw.githubusercontent.com/akitaonrails/easy-subtitle/master/install.sh | bash

# Ou baixa o binário direto dos Releases

Um binário. Sem Python, sem pip, sem nada.

Sobre Portar Coisas “Só Porque Sim”

Eu sempre defendi que portar software de uma linguagem pra outra só pelo fetiche da linguagem é perda de tempo. Quantos projetos foram reescritos em Rust “porque sim”? Quanto esforço gasto em reescritas que não entregaram valor novo?

Mas preciso admitir que esse experimento me fez reconsiderar.

Quando o custo de portar cai de semanas/meses pra menos de 40 minutos, a equação muda. O port do Subservient pra Crystal com Claude não foi um exercício de vaidade linguística. Eu queria um binário estático que eu pudesse jogar num server e esquecer. Sem gerenciar runtime Python, sem pip install quebrando na próxima atualização do sistema.

E o resultado não é um port mecânico. São 2.516 linhas em 42 arquivos, contra 10.220 em 6 monolíticos. O port veio com 76 testes que o original não tinha, CI com release automático pra Linux e macOS, Homebrew formula e install script com verificação de checksum.

O ponto não é que Python é ruim. É que a barreira de “será que vale a pena portar?” ficou ridiculamente baixa. Port feature-parity com testes em menos de uma hora. Difícil argumentar contra.

O repositório está aqui. GPL-3.0, como o original.

ffmpeg -i input.mkv -c:v libx264 -crf 23 -preset medium \
  -profile:v high -level 4.1 -c:a aac -b:a 128k \
  -movflags +faststart output.mp4

O que isso faz? Converte pra H.264 com qualidade razoável pra web, usando AAC no áudio e movendo o moov atom pro início do arquivo pra permitir streaming progressivo. Se você já sabia disso, parabéns. Se não sabia, bem-vindo ao clube de 99% das pessoas que usam FFmpeg copiando comandos do Stack Overflow.

E esse é o caso simples. Quer fazer um GIF animado a partir de uma sequência de PNGs? Precisa de um pipeline de duas passadas com geração de paleta:

ffmpeg -framerate 10 -i frame_%04d.png \
  -vf "split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" output.gif

Quer cortar um trecho, redimensionar pra 720p e forçar aspect ratio 16:9? Boa sorte montando o filter chain.

Eu cansei de ficar decorando flags. Queria uma CLI que eu falasse “converte isso pra MP4 otimizado pra web” e ela resolvesse. Então fiz o easy-ffmpeg.

O que o easy-ffmpeg faz

É um wrapper inteligente. Você dá o arquivo de entrada e o formato de saída, e ele analisa o vídeo com ffprobe, descobre quais streams de vídeo, áudio e legenda existem, verifica compatibilidade de codecs com o container de destino, e decide sozinho o que pode copiar direto (sem re-encoding, instantâneo) e o que precisa transcodificar.

O uso mais básico:

# Converter MKV pra MP4 (copia streams compatíveis, sem re-encoding desnecessário)
easy-ffmpeg input.mkv mp4

# Otimizado pra web (H.264 + AAC, faststart)
easy-ffmpeg input.mkv mp4 --web

# Otimizado pra celular (720p, AAC stereo, arquivo menor)
easy-ffmpeg input.mkv mp4 --mobile

# Compressão máxima (H.265, CRF 28)
easy-ffmpeg input.mkv mp4 --compress

# Qualidade alta pra streaming (H.265, CRF 18)
easy-ffmpeg input.mkv mp4 --streaming

Exemplos do que dá pra fazer

Cortar um trecho do vídeo:

# Do minuto 1:30 até 3:00
easy-ffmpeg video.mp4 mp4 --start 1:30 --end 3:00

# Os primeiros 90 segundos
easy-ffmpeg video.mp4 mp4 --duration 90

# Aceita vários formatos de tempo: 90, 1:30, 01:30.5, 1:02:30

Redimensionar:

# Pra 720p
easy-ffmpeg video.mp4 mp4 --scale hd

# Pra 1080p
easy-ffmpeg video.mp4 mp4 --scale fullhd

# Presets: 2k (1440p), fullhd (1080p), hd (720p), retro (480p), icon (240p)

Mudar aspect ratio:

# Forçar 16:9 (adiciona barras pretas se necessário)
easy-ffmpeg video.mp4 mp4 --aspect wide

# Formato TikTok/Stories (9:16 vertical)
easy-ffmpeg video.mp4 mp4 --aspect tiktok

# Quadrado pro Instagram
easy-ffmpeg video.mp4 mp4 --aspect square

# Croppar em vez de adicionar barras
easy-ffmpeg video.mp4 mp4 --aspect wide --crop

Sequência de imagens pra vídeo:

# Detecta automaticamente o padrão de numeração (frame_0001.png, frame_0002.png...)
easy-ffmpeg /pasta/com/frames/ mp4

# GIF animado com paleta otimizada
easy-ffmpeg /pasta/com/frames/ gif

# Sequência de imagens em 720p a 30fps
easy-ffmpeg /pasta/com/frames/ mp4 --fps 30 --scale hd

Ver o que vai fazer sem executar:

easy-ffmpeg video.mkv mp4 --web --dry-run
# Mostra o comando ffmpeg exato que seria executado

Combinar tudo:

# Cortar, redimensionar e comprimir pra mandar por WhatsApp
easy-ffmpeg video.mkv mp4 --start 0:30 --end 2:00 --scale hd --compress

E se você rodar easy-ffmpeg sem argumentos num terminal interativo, abre um modo TUI com seleção de arquivo por fuzzy search, escolha de preset por menu, e input de tempos com validação – tudo sem precisar lembrar de nenhuma flag.

Por que Crystal

Faz anos que eu não mexia com Crystal. A última vez foi pra brincar, antes da versão 1.0. E eu queria revisitar.

Crystal ocupa um nicho interessante. Go e Crystal competem pelo mesmo espaço: linguagens compiladas pra aplicações, que geram binários estáticos, com garbage collector e sem dependência de runtime. Mas a abordagem é bem diferente.

Go é famoso por ser deliberadamente simples. Sem generics por anos (só chegaram na 1.18), sem exceções (error returns), sem expressividade. O argumento é que isso facilita leitura e manutenção em equipes grandes. Na prática, resulta em código verboso e repetitivo, com if err != nil em todas as linhas.

Crystal tem tipagem estática com inferência, macros em tempo de compilação, blocos como closures (igual Ruby), exceções, generics desde sempre, e uma sintaxe que qualquer Rubista reconhece:

# Crystal: ler um JSON e extrair dados
streams = json["streams"].as_a.map do |s|
  StreamInfo.new(
    codec: s["codec_name"]?.try(&.as_s) || "unknown",
    width:  s["width"]?.try(&.as_i) || 0,
    height: s["height"]?.try(&.as_i) || 0,
  )
end

# Go equivalente: seria 3x mais linhas com type assertions e error checks

A stdlib do Crystal tem HTTP server, JSON parsing, YAML, regex, fibers (green threads com scheduler cooperativo), channels (igual Go), e até IO::FileDescriptor com raw mode pra terminal – que eu usei pro modo interativo. Concorrência funciona com spawn (equivalente ao go do Go) e Channel (idêntico ao chan do Go). A diferença é que tudo vem com a ergonomia do Ruby.

Pra uma CLI que precisa compilar num binário estático sem dependências, rodar em Linux e macOS, e ser distribuída como download direto – Crystal é perfeito. O compilador gera binários nativos, e com o Docker Alpine dá pra fazer static linking com musl pra Linux. O binário final do easy-ffmpeg tem ~6MB.

Eu considero Rust melhor pra código de sistemas (kernels, drivers, databases, coisas onde ownership e lifetime importam). Mas pra uma CLI de conversão de vídeo? Rust seria overkill. Crystal dá o mesmo resultado final (binário estático e rápido) com um terço do código e sem brigar com o borrow checker.

Os números

O projeto inteiro foi construído em uma tarde. 10 commits entre 18:32 e 21:33 do dia 7 de março de 2026. Três horas.

Linguagem    Arquivos    Linhas    Código
Crystal      13          2.823     2.342
Shell        1           109       91
Markdown     1           266       210
YAML         2           46        34
─────────────────────────────────────────
Total        20          3.326     2.419

2.342 linhas de Crystal fazem: CLI com 5 presets, análise de mídia via ffprobe, planejamento inteligente de conversão com matriz de compatibilidade de codecs, progress bar com ETA, modo interativo com fuzzy search, suporte a sequências de imagem e GIF, e trimming/scaling/aspect ratio com validação.

A ferramenta já está com CI/CD no GitHub Actions, compilando binários estáticos pra Linux (x86_64 e arm64) e macOS (arm64), com instalação via curl one-liner:

curl -fsSL https://raw.githubusercontent.com/akitaonrails/easy-ffmpeg/master/install.sh | sh

Três horas de uma tarde, da primeira linha de código ao release no GitHub com binários pra três plataformas. O FFmpeg continua fazendo o trabalho pesado – eu só coloquei uma interface decente na frente.

O repositório está aqui. MIT license.

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”.

TL;DR: Eu sempre “abri as pernas” pra IA. Mas se você só assistiu clipes dos podcasts, entendo porque está confuso. Vou explicar.

Alguém lembra deste meu video: “16 Linguagens em 16 Dias”? É do final de 2023 (1 ano depois do lançamento do primeiro ChatGPT) e é sobre a primeira Rinha de Backend. Como vocês acham que eu fiz código em 16 linguagens em 16 dias??

Eu uso IA pra fazer código desde o começo de 2023 (3 anos já). Não comecei agora: eu nunca parei. 🤷‍♂

“Mas você disse que IA nunca ia ser boa, você odeia IA”

Isso foi o que você entendeu porque é preguiçoso e só assiste a clipes fora de contexto ou tweets fora de contexto. Se lesse meu blog, eu tenho literalmente dezenas de posts (particularmente de 2 anos pra cá) detalhando cada aspecto da evolução e uso de IAs (seja pra código, seja pra imagens, seja pra 3D modelling).

“Empolgação?”

E quanto à minha famosa frase:

“Sua empolgação com IA é inversamente proporcional ao seu conhecimento sobre IA” ?

Continua correta. É que nem quem falava que Low Code ia substituir todo programador. Não vai. Mesma coisa agora: por melhor que a IA seja, ela não vai substituir todo programador. Só os ruins, como já expliquei neste outro rant.

Programadores como eu não têm nenhum problema: nós somos os tomadores de decisão que conseguem decidir o que IAs não conseguem hoje e nunca vão conseguir (é uma impossibilidade na fundação da computação, já volto nisso).

Os “empolgados” que eu falei, é todo não-programador startupeiro que - com ou sem IA - me lança código porcaria em produção e daí acontecem coisas como o fracasso do app “Tea”, lembram?

Não houve nenhuma tentativa de “hacking”; o banco de dados deles já estava aberto ao público em produção: qualquer um podia só baixar. Isso é um cara “empolgado com IA”.

Ou os idiotas que já demitiram todos os seus programadores porque acha que o código de IA vai ser muito melhor. Spoiler alert: não vai.

Aí você fica mais confuso. “Você não gosta de IA, então?” Não, não, eu gosto. “Mas se gosta é porque ele já é inteligente?” Não, não. Veja como sua linha de raciocínio não faz sentido.

“Papagaio Estocástico?”

Me lembraram hoje que eu disse também:

“IA é só um gerador de textos glorificado”

Confusos? “Como ela pode ser boa se é só um gerador de textos??”

Eu realmente não entendo essa linha de raciocínio. Geradores de texto são objetivamente bons. Eu e você usamos todos os dias o auto-corretor de todo app de e-mail e mensagens. Sejam os do teclado de iPhone ou Android. Seja Grammarly. Nenhum de vocês vai dizer que ela tem “personalidade” ou mesmo “inteligência”, mas acho que todos concordamos que ela é muito útil. Mesmo errando, de vez em quando, na maior parte do tempo conserta nossos textos direitinho, não?

GPT ou Claude ou GLM ou Gemini ou DeepSeek, todos eles continuam sendo “papagaios estocásticos” ou “geradores de texto glorificados”.

• Papagaio estocástico: algo que repete coisas com método aleatório ou parcialmente aleatório (existe um elemento de entropia)
• Geradores de texto: utilizam cálculo probabilístico (transformers no lado complicado, ou cadeias de Markov, no lado simples) pra tentar descobrir a palavra/token mais provável, dado do texto anterior.

Toda “IA” (mais corretamente “LLM”) são exatamente assim desde que foram lançadas em 2022 até hoje: gigabytes de matrizes hiper-dimensionais de pesos e probabilidades onde seu texto/prompt é calculado contra essas matrizes pra definir o “próximo token”. Concatena esse novo token no texto original e recalcula tudo de novo nas mesmas matrizes (mais corretamente, tensors), sorteia o próximo token de um pequeno grupo de probabilidades, concatena, repete, e segue assim.

Isso é um “gerador de textos”. Mas sim, eles são tão bons que “parecem” até ter personalidade nas respostas. E seres humanos são muito facilmente enganados a “antropomorfizar” coisas que não humanos. Não precisa de muita coisa.

Em 2023, no video “Entendendo como ChatGPT Funciona” eu explico sobre o Teste de Turing, um dos primeiros aplicativos “conversacionais” que passam no teste, a “Eliza”, que já passava no teste, e sem precisar de IA.

Por isso eu disse que são “glorificados”, porque todos que tem pouco conhecimento de IA, pensam nela como o macaco do filme pensa no monolito: como uma divindade que precisa ser glorificada.

“Mas e o Flow?”

“Mas Akita, no Flow você era contra IAs.”

Nope, de novo, você só assistiu clipes. Veja como eu abro a conversa: estou falando da histeria em torno do “Report AI 2027”, estou falando das asneiras do Sam Altman de que eles estavam bem próximos de atingir “AGI” (Inteligência Artificial GERAL, uma inteligência que, igual um humano, raciocina e decide as coisas sozinho e é capaz de evoluir autonomamente). E todas as controvérsias sobre IAs que chegavam num “plano” pra matar o dono (o que eu chamo de “fanfics”).

Daí eu passo horas explicando em detalhes a história e exatamente como é feito o “cálculo de próximo token”, como também dei mais detalhes aqui no blog. E sempre dizendo que precisa existir alguma “nova descoberta” (que ainda não aconteceu). Enquanto cada novo GPT ou Claude forem só uma evolução do anterior, existem limites. E eu expliquei os limites.

Não é uma “questão de tempo”. Isso não existe. Mesmo nunca tendo ido pra, digamos, Saturno, nós sabemos o que é necessário e o principal: quanto custa. “COM A TECNOLOGIA ATUAL” - que é sempre a premissa - não tem como/não faz sentido prático.

Amanhã pode surgir uma “nova descoberta” que mude tudo. Mas enquanto ela não aparece, não podemos “contar com isso”. E toda minha explicação é com base nessa premissa. E a conclusão é objetiva e matemática:

AGI não é alcançável. Isso não mudou.

Não significa que as IAs atuais sejam INÚTEIS. Essa é a contra-conclusão que eu não consigo entender o raciocínio também. Em todos os podcasts, depois do primeiro, eu voltava dizendo: “Do jeito que eu falo, alguns parecem entender que eu não gosto de IAs, mas é o contrário: eu gosto.”

Cansei de repetir isso nos podcasts, no blog, no X, mas essa é a parte que todo mundo faz de conta que não está lá e OMITE. Por isso sempre deixo tudo por escrito aqui no blog e, como falei, vocês podem ver que eu já usava desde 2023 - 3 anos atrás.

Em resumo: TUDO que eu disse nos últimos videos do meu canal e nos podcasts, CONTINUAM VALENDO. A explicação continua correta. O que está errado são SUAS CONCLUSÕES. Reveja e interprete literalmente e não subjetivamente, com a falta de conhecimento que vocês tem. Não ignorem os termos que eu falei que vocês não entendem. O argumento só faz sentido se for completo, e ele custou 4 horas pra eu explicar, em cada video.

Recado aos “Empolgados”

Eu disse isso no X esses dias:

Não importa se quer chamar de “Vibe Code”, “Agentic Engineering”, “IA Assisted Programming”, é tudo bullshit.

TUDO agora é “programar com IA”.

E só tem dois jeitos de fazer isso: o certo e o errado. O jeito errado é como vocês e o dono do app Tea (provavelmente, supostamente) fazem: deixam a IA fazer o código, não sabem revisar nem criticar esse código, sobem pra produção e deixam usuários usarem, sem saber dos riscos.

O jeito certo: eu passei DOIS MESES escrevendo mais de VINTE POSTS neste blog explicando o jeito certo, que eu chamei de “Agile Vibe Code”, mas é basicamente “Engenharia de Software aplicada à IA” e adivinhe: precisa ter estudado e experiência pra saber.

Não é 2026 e não vai ser 2027 nem tão cedo quanto você pensa que o Claude ou Codex vão “substituir TODOS os programadores”. Não, vão SIM substituir todos os ruins e isso é excelente! Novamente, leia este rant.

Você nunca vai conseguir fazer um “novo Linux” e “substituir o Linus Torvalds” com IA. Vai conseguir “copiar partes”, sim. Copiar não é suficiente. Programador ruim já copiava antes, e isso nunca os tornou bons.

Recados aos “Haters de IA”

Desistam, é um caminho sem volta. Assim como foi mobile, assim como foi a internet, assim como foram micro-computadores, etc. A caixa de pandora já foi aberta, não tem como fechar mais. IAs vieram pra ficar.

“Mas você disse que IA é uma bolha que ia estourar!”

De novo, ou vocês se fazem de bobo ou são bobos.

A Bolha da Internet de 2001 estourou, mas a Internet não desapareceu. Pelo contrário, ela aumentou! Quem sumiu foram as empresas que acharam que iam ganhar dinheiro fácil aproveitando a onda da bolha, e todo mundo que acreditou cegamente. Porém, quem foi “Hater de Internet”, perdeu também.

A esta altura, todo argumento contra IA já soa como uma desculpa mal feita. Vamos ver algumas:

“IA comete vários erros, vira e mexe eu vejo um código meia boca.”

É verdade, e justamente por isso falei pra não se empolgar à toa. Ela comete erros, eu pego todos os dias. Até o ano passado, a taxa de erro vs acertos era alta o suficiente pra eu não conseguir recomendar que qualquer amador usasse no dia a dia. Só quem presta muita atenção e sabe corrigir - como eu.

Porém, em 2026, essa taxa melhorou significativamente. Ela de fato acerta mais do que erra agora, o suficiente pra eu conseguir confiar nela sem “micro-gerenciar” cada passo.

A verdade é que todo programador humano erra, e erra BASTANTE. Quem erra tem viés de confirmação e não acha que erra tanto. Só quem vê de fora - alguém como eu, que já gerencei centenas de programadores em dezenas de projetos - sei que eles erram muito mais do que estão preparados pra admitir.

Eu CANSEI de pedir pra sempre só subir PR com testes unitários: todo mundo ignora.

Eu CANSEI de pedir pra sempre pelo menos rodar uma vez na própria máquina pra ver se está funcionando, do que eu puxar o PR e descobrir que nem executa: todo mundo ignora.

Eu CANSEI de pedir pra não só dar copy e paste do stackoverflow, e pelo menos ajustar a adaptar pro nosso projeto. Todo mundo ignora.

Eu CANSEI de pedir pra não jogar tudo no mesmo arquivão e fazer refactoring de tempos em tempos pra não aumentar débito técnico: todo mundo ignora.

Eu CANSEI de pedir pra não subir mais commits com mensagens de “bug fix”, sem explicar o que tem lá exatamente: todo mundo ignora.

Eu CANSEI de pedir pra lembrar de atualizar a documentação quando mudar alguma funcionalidade, pra facilitar quem vai pegar pra testar: todo mundo ignora.

Eu CANSEI de pedir pra cobrir um bug fix com teste de regressão pra não vermos o mesmo erro de novo. O mesmo erro sempre se repetia: todo mundo ignora.

Eu CANSEI de pedir pra seguir as convenções que concordamos no projeto e não fazer código diferente, com outros padrões. Todo mundo ignora.

Eu CANSEI de pedir pra ajustar scripts de deploy, CI ou coisas assim quando caem pedaços que afetam a infra: todo mundo ignora.

Eu CANSEI de pedir pra não acumular um monte de código que não faz sentido junto e não dar git add . no final e só escrever “nova feature” e comitar tudo junto. Todo mundo ignora.

Esses são só alguns exemplos. Sabe qual a novidade: o Claude e o Codex não ignoram. Tudo isso que listei, que acontece em TODO projeto com humanos, não importa o tamanho do projeto, não acontece mais pra mim com Claude.

Entendam: isso tudo deveria ser o básico do básico, nível estagiário. Mas eu CANSEI de pedir pra sênior tomar mais cuidado, pra não dar mau exemplo pros júniors: TODO MUNDO IGNORA.

E agora, todos esses que ME CANSARAM, são justamente os que se tornaram “Haters de IA”. Mas é lógico, a IA faz tudo que eles NÃO FAZEM. Olhem no espelho e reflitam se seu código era tão bom assim (Spoiler: não era).

90% de todo código produzido, não é nem de perto alguma coisa como “otimização na solução de memory management do Linux” ou “bug fix de regressão de performance no drivers do file system” ou “melhoria no algoritmo de segurança do firewall” ou “reescrever esta parte antiga de Assembly em C”..

90% da maior parte do código produzido no dia a dia é MUNDANO, é consumir uma API, é fazer um front-end, é mais um relatório, mais um CRUD, mais uma validação de e-mail, mais um job de limpeza, mais um script de deploy. Absolutamente NADA realmente “interessante”.

O que eu gostei das LLMs? Ela REMOVE de mim todas as tarefas mundanas e me deixa focar nas partes que eu gosto: a pesquisa, a formação de hipóteses, os benchmarks, os testes a/b pra conseguir tomar decisões melhores, os testes de integração que garantem que as diversas partes do meu sistema funcionam mesmo. Tudo que antes não dava pra fazer, porque 90% do meu tempo era ocupado consertando a porcaria do CSS de alguém.

Eu ODEIO mexer em CSS. Já passou da hora de não precisar mais.

Eu ODEIO fazer CRUD. Já passou da hora de não precisar mais.

Eu ODEIO fazer o setup inicial de ambiente de dev pra cada projeto diferente. Já passou da hora de não precisar mais.

Eu ODEIO ter que fazer especificação de coisas idiotas como mapear campos numa API mal feita de fintech/banco. Já passou da hora de não precisar mais.

Eu ODEIO ter quinhentos frameworks mal feitos de front-end pra costurar tudo junto e rezar pra funcionar na tentativa e erro. Já passou da hora de não precisar mais.

Eu ODEIO ter que participar de reunião de sprint, onde o que é pedido vai sendo modificado ao longo do caminho porque ninguém prestou atenção. Já passou da hora de não precisar mais.

Eu ODEIO ter impedimento, ter que ficar esperando, porque outro dev ou outra equipe tá trabalhando em coisa que afeta o meu lado e no final vou gastar dias depois só ajustando conflito na mão. Já passou da hora de não precisar mais.

Quem são os “Haters de IA”: justamente todo mundo que me causava impedimento antes, responsáveis por esticar mais do que deveria, e entregar em qualidade ruim, todas as tarefas MUNDANAS, e achar que está fazendo grande coisa.

O que a História me Ensinou

Computadores entendem instruções de máquina. Elas estão cagando e andando pras nossas “linguagens favoritas”. É o que eu gastei horas explicando nos podcasts e nos videos do meu canal.

Foda-se sua linguagem/framework favorito. Foda-se seu design pattern favorito. No final, a máquina só se interessa pelo binário que vai rodar.

Antigamente, era extremamente custoso informar essas instruções pra máquina. Tínhamos que, literalmente, entrar bit a bit com cada instrução, no endereço exato na memória. Seja com FIOS ou com SWICHES, UM BIT DE CADA VEZ:

Felizmente, as coisas evoluíram e melhoramos as formas de “INPUTAR” instruções e dados. Seja com papel perfurado ou teletypes (máquinas de escrever elétricas adaptadas como terminais burros):

Era caro programar, porque era MUITO custoso “consertar” um erro. Não tinha “backspace” fácil. Na hora que ia digitar, você tinha que ter MUITA CERTEZA do que ia digitar, sem errar!

Mesmo no fim dos anos 70, começo dos anos 80, já tinha evoluído muito, mas ter armazenamento permanente era uma coisa OPCIONAL na maioria dos “micro” computadores. Tínhamos que digitar os programas do zero pra rodar e quando a máquina desligava, o que estava em RAM apagava e perdíamos tudo. Gravar era caro, uma das opções mais populares, era gravar em fita cassete:

Mas pra gravar/ler somente míseros 1 kilobyte de dados, poderia levar MAIS de 20 segundos. Um joguinho de 10 kilobytes (que é bem pouco), levaria quase 4 MINUTOS pra carregar.

Você nem tem ideia do que significam 10 kilobytes. Qualquer ícone PNG ou SVG ou qualquer arquivinho idiota de JS no seu website tem muito mais do que isso.

Tudo isso pra dizer o seguinte:

• computadores rodam instruções de máquina, até hoje
• sempre foi caro informar essas instruções pro computador

Hoje em dia temos SSD NVME que me permitem ler 1 gigabyte hoje (<70ms) mais rápido do que eu lia 10 kilobytes nos anos 80.

Mas pra compensar, nossos programas foram ficando mais e mais complexos e “gordos”. Uma vez que memória, armazenamento, barramento de dados, tudo ficou de ordens de grandeza mais rápido, nós humanos, fomos jogando mais e mais dados neles. Um editor de textos hoje, faz a mesma coisa que um editor de textos nos anos 80: edita texto. Mas, lógico, tem muito mais funcionalidades: fontes bonitas, smooth scrolling, auto-correct, auto-format, etc.

Trocamos recursos por conforto, e isso é uma boa coisa.

Falei nos meus videos, nos posts de rant recentes, que foi uma coisa muito ruim a bolha de startups que estourou só em 2022 (e continua repercutindo até hoje). Trocamos eficiência de programação por programadores ruins baratos. Pra que tentar ser mais eficiente se era “barato” só colocar mais “braços” pra resolver o problema? A mesma mentalidade que permitiu o surgimento de fábricas de software baratas nos anos 2000, fazendo software ruim como se amanhã não houvesse.

Eu, pessoalmente, fico muito contente por finalmente termos dado mais um passo para conseguir informar instruções à máquina com mais eficiência. LLMs, nossos papagaios estocásticos, são, de fato, a forma mais eficiente de produzir 90% das instruções que precisamos fornecer pras máquinas computarem o que precisamos. Da mesma forma que eu não sinto falta de cartão perfurado, nem de teletipos, nem de fita cassete, se eu não precisar mais usar uma IDE no meu dia a dia, não vou sentir falta.

Eu não escolhi me tornar um programador pra virar operador de IDE. Quando eu comecei, nem existia o conceito de IDEs.

Eu escolhi me tornar um programador porque eu gosto da ideia de instruir uma máquina a computar as coisas que eu quero. Seja uma planilha, seja um jogo. COMO essas instruções são inputadas, não é o principal pra mim. Nunca foi. IDEs foram só uma pequena fase dentro de décadas de carreira e não serão as últimas.

Eu não entendo o raciocínio nem dos empolgados demais nem dos haters demais. Por que você precisa glorificar um martelo? Por que você precisa odiar um martelo? Era só isso que eu precisava dizer 🤷‍♂

Algumas Desculpas Idiotas

“Mas a Anthropic (ou OpenAI) são do mal”

Foda-se. Microsoft também era, passou até por julgamento anti-truste no ano 2000 que quase dividiu a empresa. Mesmo se eu prefiro Mac ou Linux hoje, Windows deixou de ser o sistema operacional mais usado do mundo? Não.

“Mas IA usa muita energia, e o meio ambiente?”

Foda-se. Isso nunca foi um consenso (e mais provavelmente nunca vai ser e nem é um problema). O planeta já passou por 5 ou 6 grandes de eventos de extinção antes, o último foi um meteoro que caiu e dizimou os dinossauros. Já passamos por múltiplas Eras do Gelo. O planeta vai continuar bem, não se preocupem.

O problema da última década foi a imbecilidade de não terem investido em mais usinas nucleares - e agora essa opção finalmente voltou pra mesa. Eu disse no Flow que a Alemanha fechando as delas foi uma das decisões mais idiotas de todos os tempos, e reafirmo: foi.

São as duas mais prevalentes de que me lembro hoje. Mas é isso: qualquer coisa é desculpa agora. A caixa de pandora foi aberta, não tem mais volta.

O nome é Frank Sherlock — um sistema local de catalogação e busca de imagens usando IA. Você aponta pra uma pasta (pode ser um NAS com terabytes), ele escaneia tudo, classifica cada arquivo usando um LLM de visão rodando localmente na sua GPU, e te dá busca full-text sobre o conteúdo. Não é cloud, não manda nada pra fora, roda 100% na sua máquina.

Eis alguns exemplos de textos que ele extraiu de algumas das minhas imagens:

E olha os detalhes do Surya OCR: ele leu direitinho o texto na tela do Game Boy:

Mais do que isso, eu tenho diretórios de screenshots de comprovantes de pagamento. Nunca mais ia achar nada ali, mas agora:

Embora ele faça alguns erros, claro, animes obscuros (ele fica achando que tudo que ele não reconhece é Evangelion 😂). Mas muitos ele surpreendentemente acerta também. Mas as descrições em si já ajudam muito.

Vai precisar de um mínimo de GPU (eu só testei na minha 5090, mas é pra baixar modelos menores pra GPUs menores, e teoricamente suporta AMD e Mac também, mas ainda não testei - aceito Issues e Pull Requests pra quem quiser fazer beta-testing em Mac e Windows). Basta ter o Ollama instalado e rodando; opcionalmente, Python (pra ter o Surya OCR, que é opcional, mas é o melhor).

Vou colocar como “1.0” quando tiver mais gente testado em Windows/macOS e eu tiver os certificados pra assinar os executáveis direitinho. Esta é uma versão “beta” ainda! Compilem e rodem vocês mesmos em suas máquinas, tá tudo explicado no README.

E eu fiz isso com meu “Agile Vibe Coding” — basicamente, programar em parceria com um LLM (no caso, Claude Code).

Agile Vibe Coding funciona. E funciona muito bem. Mas a ideia é só 10% do trabalho. Os outros 90% são engenharia.

Engenharia requer experiência, julgamento, e saber fazer as perguntas certas. O LLM é um executor excelente. Mas quem decide o que executar, em que ordem, e por quê, esse continua sendo o trabalho do desenvolvedor.

Tem um discurso crescente de que qualquer pessoa com uma boa ideia pode construir software agora. Num certo sentido, sim, você pode colocar um protótipo no ar rápido. Mas a distância entre “roda na minha máquina” e “software que funciona em 3 sistemas operacionais, sobrevive a cancelamentos no meio do processamento, não corrompe dados, e escala de 94 arquivos de teste pra 500 mil em produção” continua sendo enorme. Esse gap é engenharia, e engenharia ainda exige alguém que saiba o que está fazendo.

Vou contar a história completa: da pesquisa inicial ao release, passando por benchmarks, prova de conceito, decisões de arquitetura, CI/CD multi-plataforma, e tudo que ficou entre “eu tenho uma ideia” e “aqui está o AppImage, o DMG e o MSI”.

A Ideia Original

Tudo começou com uma pergunta simples: será que LLMs open-source de visão conseguem classificar conteúdo de verdade? Não estou falando de “mulher na praia” — isso qualquer modelo faz. Estou falando de olhar pra uma imagem e dizer “isso é a Ranma, do anime Ranma 1/2 da Rumiko Takahashi, numa cena do OVA The Battle for Miss Beachside”. Será que chegamos nesse nível? (TL;DR não, mas o suficiente)

E se chegamos, dá pra fazer um catálogo inteligente de arquivos? Algo que eu aponte pro meu NAS com terabytes de mídia acumulada ao longo de décadas e consiga buscar por conteúdo, não por nome de arquivo? Quem tem um NAS em casa sabe: depois de alguns anos, os arquivos acumulam e a organização de diretórios simplesmente para de escalar. Você sabe que tem aquele comprovante de pagamento de 2019 em algum lugar, mas o arquivo se chama IMG_20190315_142301.jpg e está num diretório com mais 3 mil fotos.

Meu hardware: AMD 7850X3D, RTX 5090, Arch Linux. Restrição absoluta: nada de APIs remotas, nada de OpenAI, nada de cloud. Tudo open-source, tudo local. Se eu vou processar terabytes de arquivos pessoais, incluindo documentos financeiros e fotos privadas, não quero mandar nada pra servidor de terceiros. Fora que o custo de API cloud pra esse volume seria proibitivo.

Mas primeiro: pesquisa. Sem saber se a tecnologia entrega o que eu preciso, não faz sentido construir nada. Scripts pequenos, protótipos rápidos, modelos diferentes. Ver o que funciona antes de escrever a primeira linha de código do app de verdade. Esse é um padrão que eu sigo há anos: valide a suposição mais arriscada primeiro. Se o LLM de visão não conseguir classificar decentemente, todo o resto é desperdício.

Pesquisa A/B: Benchmark Driven Development

Essa é a parte que a maioria das pessoas pula, e é exatamente onde a experiência faz diferença. A tentação de pular direto pra implementação é enorme. “Vou usar o modelo X porque li num blog que é bom.” Não. Antes de escolher modelo, framework, ou arquitetura, eu montei um benchmark formal.

Montei um corpus de teste com 94 arquivos: 60 imagens (fotos, screenshots, anime, documentos, receipts), 9 áudios, 13 vídeos e 12 documentos. Pra cada arquivo, criei um ground truth em JSON com a classificação correta — tipo, descrição, série (quando aplicável). Esse ground truth é o que permite medir accuracy de verdade, não “olhei o resultado e pareceu OK”.

O benchmark tem 6 fases, cada uma respondendo a uma pergunta específica:

1. Metadata: quanto custa extrair metadata básica? (resposta: barato, 0.07s/arquivo)
2. Imagens: qual modelo de visão é melhor? Qual OCR?
3. Áudio: Whisper funciona? Qual tamanho de modelo?
4. Vídeo: classificação por frames funciona?
5. Catálogo unificado: o pipeline completo integrado funciona?
6. Projeção de custo: quanto tempo e dinheiro pra processar um NAS real?

Fase 2: Visão — O Resultado Que Ninguém Esperava

Testei qwen2.5vl:7b, llava:13b e minicpm-v:8b em 30 imagens rotuladas. O resultado:

O modelo de 7B parâmetros ganhou de lavada dos maiores. Não é typo. O qwen2.5vl:7b bateu o llava:13b (quase o dobro do tamanho) em todas as métricas, e ainda foi 3x mais rápido. Isso contradiz a intuição de “modelo maior = modelo melhor”. Na prática, depende do task e do prompt.

Naturalmente, a próxima pergunta é: e o 32B? Mesmo modelo, versão gigante. A gente deve conseguir bem mais, certo? Errado:

O 32B deu +0.06 em series accuracy (literalmente 1 acerto a mais em 16 itens rotulados) e custou 29x mais tempo. Pra quem vai processar centenas de milhares de arquivos, essa troca não fecha. 29x mais lento significa que um job de 6 horas vira um job de uma semana.

Aqui faço um comentário sobre ferramenta: fiz a primeira rodada com Claude Code e tinha pedido pra ele escolher os modelos que achava melhores. Mas depois decidi ir pro GPT Codex e ele fez outras sugestões que achei interessante testar. Em resumo: tenho achado Codex muito melhor pra experimentação e código exploratório, pra pesquisa mesmo. Claude eu acho melhor quando já sabemos melhor exatamente o que queremos.

Com o Codex, testei os novos candidatos qwen3-vl:8b e qwen3-vl:30b-a3b com 3 repetições para fins de significância estatística. Resultado? Ambos piores que o qwen2.5vl:7b — type_accuracy de 0.55 contra 0.89 do incumbent, com intervalo de confiança de 95% que nem se aproxima. E ainda mais lentos: 2x e 2.2x respectivamente. Modelo mais novo nem sempre é modelo melhor pro seu caso de uso. O qwen3-vl frequentemente retornava JSON truncado ou mal-formado — uma regressão real em robustez.

OCR: Surya vs Ollama Vision

Para extração de texto (documentos escaneados, receipts, screenshots com texto), testei dois engines:

Surya encontra texto em muito mais arquivos (83% vs 58%), mas é 5x mais lento. Quando encontra texto, a qualidade é praticamente igual (similarity > 0.94 nos dois). Solução óbvia: abordagem híbrida. Usa Surya quando precisa de cobertura máxima, Ollama Vision como fallback rápido. O design do pipeline ficou: tenta Surya → se falhar ou não encontrar texto → fallback pra Ollama Vision. Por isso falei no começo que Surya é opcional, se não quiser instalar.

Projeção de Custo

A fase 6 fez algo que raramente vejo em projetos open-source: projeção de custo pra uso real. Com os timings medidos por tipo de arquivo, extrapolamos pra cenários de NAS:

Leve esses números com algum ceticismo porque é conta em papel de pão. $34 de eletricidade pra classificar 500 mil arquivos com GPU local. Tenta fazer isso com API do GPT-4 Vision — a $0.01 por imagem (conservador), são $5.000. O preço do meu setup (GPU + eletricidade) se paga no primeiro uso grande.

A lição: faça benchmark, não adivinhe. Eu poderia ter assumido que o modelo maior seria melhor, ou que o mais novo superaria o antigo. Os dados mostraram o contrário. ~2 horas de benchmarks me pouparam de escolhas erradas que custariam dias de retrabalho (antigamente eu diria “semanas”).

Prova de Conceito em Python

Com os benchmarks em mãos, o próximo passo foi validar o pipeline completo antes de partir pro Rust. Não o pipeline de benchmark (que testa cada modelo isoladamente), mas o pipeline de classificação real — a sequência exata de chamadas que o app final vai fazer pra cada arquivo.

Criei um protótipo em Python — 754 linhas em um único arquivo (classification/run_classification.py) — que implementava a estratégia vencedora dos benchmarks.

O pipeline tem 4 estágios de enriquecimento:

1. Classificação primária: manda a imagem pro qwen2.5vl:7b com prompt estruturado, pede JSON com tipo, descrição, tags, confidence
2. Enriquecimento anime: se o tipo primário for anime/manga/cartoon, faz uma segunda passada com prompt especializado pedindo série, personagem, cena, artista
3. Documento/OCR: se for documento ou receipt, extrai texto com Surya e/ou Ollama Vision, depois pede dados estruturados (datas, valores, IDs de transação)
4. Output: grava resultado em YAML espelhando a estrutura de diretórios de origem

A parte mais crítica é o parsing de JSON do LLM. Quem já trabalhou com output de LLMs sabe que eles são… criativos com formatação. Às vezes vem com markdown fences (json ... ). Às vezes tem texto antes e depois do JSON. Às vezes o JSON está quase certo mas falta fechar uma chave. O protótipo implementou uma cascata de 3 tentativas que depois virou a regra do projeto inteiro:

1. Parse direto: json.loads(response) — funciona em ~70% dos casos
2. Extração por balanceamento de chaves: encontra o primeiro {, conta chaves abertas e fechadas, extrai o substring — pega mais ~20%
3. Regex field salvage: se tudo mais falhar, usa regex pra extrair campos individuais (“type”: “…”, “description”: “…”) — salva os últimos ~10%

Essa cascata ficou no código Rust praticamente idêntica. PoC bem feito encurta o caminho pra produção.

Resultado: 60 imagens processadas, zero erros, 6.29s/imagem de média. O pipeline funcionava de ponta a ponta. Hora de construir o app de verdade.

Construindo o App Tauri

Nesse ponto, tentei continuar com o Codex, mas aí ele se engasgou em tentar converter o Poc em Python pra Tauri. Mas como agora as escolhas já foram feita, voltei pro Claude Code, e ele não teve problemas em mapear do Python pra Rust.

Aqui é onde o vibe coding mostra a que veio. Vou contar a timeline real, commit por commit, pra você ter noção do ritmo. Os timestamps são do git log, então são precisos.

Sábado 21/02 (19:29 → 21:08) — 6 commits, 1h39

Tudo começou com research. Seis commits de setup, scripts de benchmark, análise de resultados:

f57221c 19:29 Phase 0: Project setup with uv, environment verification
4977497 19:45 Implement all phases: metadata, image/audio/video classification
af6e3aa 19:49 Add research results report
41d6c2a 20:12 Add per-file timing, OCR phase, cost estimation
0cd1b10 21:02 Fix Surya OCR, re-run on 94-file corpus
25b3ace 21:08 Add conclusions, cost analysis, recommended pipeline

Sábado à noite, só pesquisa pura. Nenhuma linha de código do app. Mas quando fui dormir, sabia qual modelo usar, qual abordagem de OCR, e quanto ia custar em tempo e eletricidade.

Domingo 22/02 (13:05 → 23:30) — 14 commits, ~10h25

O domingo foi o dia de construção pesada. Acordei, almocei, e sentei pra trabalhar.

13:05 — Primeiro commit do dia: o protótipo Python de classificação. 749 linhas validando o pipeline completo de classificação, a cascata de JSON parsing, e o enriquecimento condicional. Esse protótipo não era throwaway — ele era o design document executável do pipeline Rust que viria depois.

Dei uma pausa pra pra dar uma saída, passear, tomar um vinho, depois voltei e continuei:

17:31 — Benchmarks atualizados com os novos candidatos (qwen3-vl:8b e qwen3-vl:30b-a3b). Três repetições cada, intervalos de confiança. Confirmaram que o qwen2.5vl:7b era a escolha certa — não por pouco, mas por uma margem enorme.

17:56 — O “big bang”: scaffold do app Tauri. 9.631 linhas inseridas num único commit. A estrutura inteira do app: Rust backend com SQLite + FTS5, React frontend, config system, scanner de arquivos, modelos de dados, query parser pra busca natural. Nesse ponto o app já buscava no banco. Não tinha classificação ainda, mas a fundação estava sólida — e é exatamente o ponto. O scaffold veio com testes, tipos TypeScript, e a arquitetura de diretórios que eu defini. O Claude gerou o código, mas a estrutura de módulos (config, db, scan, models, query_parser) veio de como eu queria organizar as responsabilidades.

19:04 — O commit mais pesado do projeto: 4.186 linhas. Classification pipeline em Rust (1.069 linhas de classify.rs — praticamente a tradução do PoC Python), geração de thumbnails (Lanczos3, 300px, JPEG 80%), scanning incremental com fingerprint, o script Surya OCR em Python, runtime detection pra Ollama, e a expansão brutal do banco de dados com upsert, touch, delete e FTS indexing. Num commit. Com 47 testes. Eu tive que tomar as decisões de arquitetura (como o cache espelha o rel_path, como o scan é dividido em duas fases, como os erros propagam), mas o Claude escreveu o grosso do código e os testes que vieram junto.

19:55 — Redesign de UI, cancellation de scan, auto-cleanup de classificações órfãs, reorganização do repo inteiro (movi tudo de research pra _research_ab_test/). CI e release workflow já configurados nesse commit — eu sabia que ia precisar deles no dia seguinte.

21:02 — DB resilience (WAL mode, backup, health check), gerenciamento de roots (adicionar, remover, listar diretórios monitorados), zoom, redesign do sidebar com tree view, fix de thumbnails. Quatro features num commit. Num workflow manual, cada uma dessas seria um PR separado com review de dias.

21:14 → 21:39 — Read-only database mode pra filesystems sandbox, resume de scans interrompidos no startup, redesign de grid tiles com hover overlay, modelo de seleção, infinite scroll. Três commits em 25 minutos. O Claude estava num ritmo absurdo.

22:41 — Multi-select com Ctrl/Shift click, preview de collage com os itens selecionados, Ctrl+C copia pro clipboard do OS.

23:30 — O grande refactor: frontend monolítico (tudo no App.tsx - se não explicar, Claude sempre faz isso) desmembrado em 15 componentes + 10 hooks + 84 testes frontend. Esse é o tipo de coisa que normalmente leva um dia inteiro de trabalho tedioso. Com vibe coding, foi um commit de uma hora. O Claude extraiu cada componente, criou os hooks, montou os testes com mocks adequados, e manteve tudo funcionando. Eu só precisei dizer “refatora esse monolito em componentes e hooks, e escreve testes pra cada um”.

Segunda-feira 23/02 (00:09 → 14:33) — 30 commits, ~14h

A segunda foi de polimento, robustez e a maratona de cross-platform.

00:09 — Abstração multi-OS: todo código específico de plataforma isolado no módulo platform/. Essa decisão, tomada cedo, salvou horas de dor no CI. Quando o Windows precisou de tratamento especial pra paths UNC, a mudança ficou contida em platform/process.rs em vez de espalhada em 8 arquivos.

00:12 → 01:18 — Sequência rápida: cargo audit no CI, remoção de duplicações, licença GPL-3.0, help dialog (F1) com exemplos de query syntax, sort controls pra resultados, sistema de migração SQLite formal, context menu (copy, delete, rename). Seis commits em pouco mais de uma hora.

09:38 — Após dormir umas 8 horas, o primeiro commit da manhã: extração do módulo LLM. O monolito de chamadas ao Ollama que vivia dentro de classify.rs foi separado em llm/client.rs (chamadas HTTP, parsing JSON), llm/management.rs (download, listagem, cleanup de modelos) e llm/model_selection.rs (seleção hardware-aware por tier). Atomic file ops pra não corromper cache se o processo morrer no meio de uma escrita.

10:54 — Extração de localização EXIF (GPS coordinates → endereço legível), modal de edição de metadata, setup instructions por OS (cada OS tem dependências diferentes pro Ollama e Python).

11:34 — Suporte a PDF: scanning, indexing e preview usando PDFium. Não é trivial — PDFium precisa de binário nativo por plataforma, renderização de páginas em imagem, detecção de páginas em branco (pra não gerar thumbnail de uma capa vazia), montagem de thumbnail com as 2 primeiras páginas com conteúdo, e extração de texto nativo como alternativa mais rápida ao OCR.

12:08 — Albums e Smart Folders. Albums são coleções manuais (o usuário arrasta arquivos pra dentro), Smart Folders são queries salvas que aparecem no sidebar e atualizam automaticamente. Duas migrações de banco, novo componente de sidebar, drag-and-drop. Em 34 minutos.

12:11 → 12:52 — Ícones SVG macOS-inspired no sidebar, suporte a argumento CLI (sherlock /path/to/folder), copy description/OCR text no context menu, fix de path do PDFium em produção, ícones e screenshots no README, script tauri no npm, sidebar toggle, titlebar dinâmico, fix de compilação Windows (imports Unix-only). Dez commits em 41 minutos. A maioria desses foram issues que apareceram no CI ou durante teste manual.

13:14 → 13:54 — A maratona de CI fixes. Auto-provision do venv Surya OCR com barra de progresso no SetupModal, regeneração de ícones com alpha channel, cargo fmt + clippy + fix de UNC paths no Windows, testes pros exemplos do help dialog, rescan de pasta individual, fix de assertions Windows, fix de permissions do release workflow. Sete commits de hardening. Cada um resolvendo um bug real que aparecia no CI matrix ou em teste.

14:26 — Drag-and-drop pra reordenar roots no sidebar, cancelamento de scan antes de deletar um root (pra não deixar o scan rodando em background num diretório que o usuário removeu — edge case sutil que poderia causar crash).

14:33 — Último commit: fix de responsividade no cancelamento de scan. Check do cancel flag após cada classificação, poll imediato em vez de esperar o próximo tick. Detalhe pequeno, impacto grande na UX.

Decisões de Arquitetura

Aqui é o que separa “deixar o LLM escrever código” de “construir software de verdade”. Nenhuma dessas decisões veio de prompt. O Claude não sugeriu nenhuma espontaneamente. Eu tive que pedir cada uma.

Princípio Read-Only

O app nunca escreve nos diretórios escaneados. Tudo — thumbnails, cache de classificação, banco de dados — fica em ~/.local/share/frank_sherlock/. Isso não é só boa prática, é respeito pelo dado do usuário. Se alguém aponta pro NAS da empresa, o app não pode sair criando .sherlock/ em cada subdiretório. Se o diretório é montado como read-only via NFS, o app precisa funcionar normalmente. Parece óbvio, mas muitos apps de catalogação que você conhece criam caches e thumbnails dentro dos diretórios de origem. (cof Synology @eaDir cof)

Scanning Incremental

Escanear terabytes de dados toda vez que o app abre seria insano. O scan é incremental em dois sentidos:

1. Fase de descoberta (rápida): caminha o filesystem comparando mtime + tamanho de cada arquivo. Se nada mudou desde o último scan, nem lê o conteúdo — apenas atualiza o marcador de “visto neste scan”. Pra um NAS com 500K arquivos onde 99% não mudou, essa fase leva segundos, não horas.
2. Fase de processamento (pesada): só pra arquivos novos ou modificados. Calcula fingerprint (SHA-256 dos primeiros 64KB), gera thumbnail, classifica com o LLM. E aqui entra a detecção de movidos: se um arquivo mudou de path mas o fingerprint é o mesmo, o app preserva toda a classificação já feita e apenas atualiza o path. Você reorganizou 10 mil fotos em pastas novas? O app detecta e não reclassifica nenhuma.

O checkpoint é por arquivo. Se o scan for interrompido (o app crashou, o usuário fechou, acabou a luz), na próxima vez ele retoma do último arquivo processado, não do zero. Isso é implementado via scan job persistence no banco: o cursor do scan fica salvo em scan_jobs.

Cancelamento Cooperativo

O scan roda numa thread separada via tokio::spawn_blocking. Para cancelar, uso AtomicBool compartilhado entre a thread de scan e o frontend. O flag é checado:

• Antes de cada arquivo na fase de descoberta
• Antes de cada classificação na fase de processamento
• Após cada classificação (pro caso de a chamada ao Ollama demorar)

Isso garante que o cancelamento responde em no máximo o tempo de uma classificação (~1 segundo), não no tempo do scan inteiro. Sem esse design, cancelar um scan de 500K arquivos poderia levar minutos — ou simplesmente não funcionar.

Resiliência do Banco

SQLite com WAL mode (permite leituras concorrentes durante escrita), health check no startup, backup automático antes de migrações, sistema de migração formal via rusqlite_migration. Cinco migrações no total:

0. Schema inicial (tabelas de arquivos, roots, scan_jobs, e a virtual table FTS5 pra busca)
1. Coluna location_text pra endereço EXIF
2. Rebuild do índice FTS (necessário após mudar a tokenização)
3. Tabelas albums e album_files pra coleções manuais
4. Tabela smart_folders pra queries salvas

As migrações são identificadas por posição e nunca podem ser editadas ou reordenadas depois de publicadas. Isso é o tipo de regra que você aprende depois de corromper o banco de produção de alguém uma vez. A regra está codificada no CLAUDE.md do projeto pra que futuras sessões de vibe coding não a violem.

Seleção de Modelo Hardware-Aware

Nem todo mundo tem uma RTX 5090. O app detecta a GPU no startup e escolhe o modelo adequado:

• GPU fraca ou sem GPU: qwen2.5vl:3b (tier small — roda em qualquer coisa)
• GPU com >= 6GB VRAM: qwen2.5vl:7b (tier medium, o default dos benchmarks)
• Apple Silicon com >= 48GB unificados: qwen2.5vl:32b (tier large, só onde a memória unificada permite sem swap)

A detecção usa nvidia-smi no Linux/Windows, system_profiler no macOS, e sysinfo como fallback pra RAM do sistema. O resultado é cacheado no AppState do Tauri pra não ficar executando subprocesso toda hora.

Multi-OS e CI/CD

Se tem uma parte do projeto que justifica ter experiência, é essa. Fazer software que compila é fácil. Fazer software que compila e passa todos os testes em Linux, macOS e Windows ao mesmo tempo te ensina humildade.

Módulo Platform

Todo código específico de OS vive em src-tauri/src/platform/:

• gpu.rs: detecção de GPU (NVIDIA via nvidia-smi, AMD via sysfs/rocm-smi, Apple via system_profiler)
• clipboard.rs: cópia de imagem pro clipboard (xclip no Linux, pbcopy no macOS, PowerShell no Windows)
• python.rs: localização de Python (python3 vs python no PATH), caminhos de venv por OS
• process.rs: abstração de execução de subprocesso com tratamento de output

Isso significa que classify.rs, scan.rs, thumbnail.rs — nenhum deles sabe em qual OS está rodando. Eles pedem pra plataforma e a plataforma resolve. Quando o Windows precisou de tratamento especial pra paths UNC (aqueles que começam com \\?\), a mudança ficou contida em platform/. Quando o macOS precisou de um import condicional, idem. O resto do codebase não foi tocado.

GitHub Actions Matrix

Dois workflows:

• CI (push + PR): build e teste em Linux, macOS e Windows. Cada push roda cargo test + npm test nos 3 OS. Inclui cargo fmt --check, cargo clippy -- -D warnings e cargo audit. Se qualquer plataforma falhar, o PR não passa.
• Release (tags v*): build via tauri-action, gera AppImage (Linux), DMG (macOS arm64), MSI (Windows), e cria um Draft Release no GitHub com os binários anexados.

Os 10+ commits de CI fix na segunda de manhã, foram a parte menos glamorosa do projeto. Coisas como:

• #[cfg(not(target_os = "windows"))] em imports que usam std::os::unix::fs::PermissionsExt
• dunce::canonicalize no lugar de std::fs::canonicalize porque o Windows gera paths com prefixo \\?\ que quebram comparações de string
• Instalar rustfmt e clippy explicitamente no runner porque nem sempre vêm no toolchain default da GitHub Actions
• Remover o target macOS Intel do release workflow (Apple Silicon only — não vale o custo de manter dois targets Mac)

Ninguém posta essas coisas no X. Mas sem elas, seu app não builda em 2 dos 3 targets.

Integrações Externas

O app depende de 3 sistemas externos. Cada um trouxe seus próprios problemas.

Ollama

O Ollama serve os modelos de visão via API REST local (porta 11434). O app faz:

• Verificação de status: checa se o Ollama está rodando e lista modelos instalados/carregados
• Download de modelo: se o modelo recomendado não está instalado, oferece download com barra de progresso via streaming da API
• Geração: manda imagem em base64 + prompt, recebe JSON (com a cascata de parsing de 3 níveis)
• Cleanup: descarrega modelos da VRAM quando não está classificando, pra não ficar monopolizando a GPU pras outras aplicações do usuário

O Ollama é o único hard requirement. Sem ele, a classificação não funciona. O SetupModal guia o usuário pela instalação e download do modelo.

Surya OCR

Surya é um engine de OCR em Python que roda localmente. O problema: o app é Rust e não pode depender de uma instalação Python do sistema. A solução:

• O app mantém um Python venv isolado em ~/.local/share/frank_sherlock/surya_venv/
• O script surya_ocr.py é bundled como resource do Tauri (empacotado no binário)
• No primeiro uso, o SetupModal oferece provisionar o venv automaticamente (encontra Python, cria venv, pip install surya-ocr + dependências)
• A classificação chama o script via subprocess, passa a imagem como argumento, lê o texto extraído do stdout

O Surya é um soft requirement: se não estiver instalado, o app funciona normalmente — só não vai ter OCR dedicado. O pipeline degrada gracefully pra usar Ollama Vision como fallback, que é pior em cobertura mas funciona. O usuário vê um aviso no setup, não um erro que bloqueia o uso.

PDFium

Pra PDFs, eu precisava de extração de texto nativo e renderização de páginas pra thumbnail. PDFium é o engine do Chrome pra PDFs, e tem bindings Rust via pdfium-render.

O binário do PDFium é baixado por um script (scripts/download-pdfium.sh) e bundled via lib/ nos resources do Tauri. Cada plataforma recebe o binário correto (.so, .dylib, .dll). O lib/ é gitignored — os binários são baixados no build, não versionados.

O pipeline de PDF:

1. Tenta extrair texto nativo (sem OCR) — muitos PDFs já têm text layer
2. Se tiver texto suficiente, usa direto pra indexação (mais rápido e mais preciso que OCR)
3. Se não, renderiza a página e manda pro pipeline de imagem (Ollama Vision)
4. Detecta páginas em branco, encontra a primeira página com conteúdo real
5. Gera thumbnail como montagem das 2 primeiras páginas com conteúdo (dá uma noção melhor do documento do que só a capa)

O que Agile Vibe Coding Realmente É

OK, agora o ponto que realmente importa. O motivo de eu estar escrevendo isso.

O Que o Claude Fez

• Escreveu a maior parte do código Rust e TypeScript
• Gerou 166 testes Rust e 172 testes frontend
• Implementou o parsing de JSON com 3 níveis de fallback
• Configurou CI/CD com matrix de 3 OS
• Fez refactors massivos (monolito → 15 componentes + 10 hooks)
• Lidou com edge cases de encoding, paths Unicode, e formatos de arquivo exóticos
• Escreveu queries SQL, migrações, índices FTS5
• Implementou detecção de GPU, clipboard por OS, resolução de Python
• Criou o setup flow com barra de progresso e download de modelo
• Debugou e fixou dezenas de issues de compilação cross-platform

A velocidade é difícil de descrever sem parecer exagero. O commit das 19:04 de sábado, aquele de 4.186 linhas com 47 testes, levou cerca de uma hora incluindo minha revisão. Um dev humano, mesmo bom, levaria um dia inteiro pra escrever isso com a mesma cobertura de testes.

O Que Eu Fiz

• Decidi fazer benchmarks antes de escrever qualquer código de app
• Escolhi Tauri em vez de Electron (menor footprint, Rust nativo, sem Node runtime em prod)
• Defini o princípio read-only como regra inviolável
• Projetei o scan incremental com detecção de move por fingerprint
• Decidi por cooperative cancellation com AtomicBool
• Exigi migração formal de schema (nada de ALTER TABLE ad-hoc em scripts soltos)
• Insisti em abstração de plataforma desde o primeiro commit multi-OS

E principalmente: fiz as perguntas chatas. “E se o scan for cancelado no meio?” virou o sistema de checkpoint. “E se o banco corromper?” virou WAL + backup + health check. “E se a pessoa não tiver GPU boa?” virou model selection por tier. “E se o Surya não estiver instalado?” virou soft requirement com fallback. “E se o usuário deletar um root que está no meio de um scan?” virou cancel-before-delete. “E se o arquivo mudar de lugar mas o conteúdo for o mesmo?” virou detecção de move.

Ah, e decidi a hora de parar de adicionar features e publicar.

Essa última é subestimada. A tentação de ficar adicionando “só mais uma coisa” é enorme quando o custo marginal de implementar é baixo. O Claude implementa qualquer feature que eu pedir em minutos. Mas software que nunca é publicado não serve pra ninguém. Saber a hora de parar é uma skill que nenhum LLM vai te dar.

O Padrão Real

Agile Vibe coding não é “pedir pro LLM fazer um app”. É pair programming com um parceiro que é rápido pra caramba, tem memória perfeita, e nunca reclama de refactor. Você diz o que quer, ele implementa, você revisa e ajusta a direção. Mas se você não sabe pra onde ir, velocidade não ajuda — você só chega mais rápido no lugar errado.

As perguntas que eu fiz — sobre resiliência, cancelamento, multi-OS, degradação graceful, detecção de edge cases — nenhuma delas veio do LLM. Vieram de anos construindo software que precisa funcionar em ambientes reais, com usuários reais, em hardware diverso. O Claude não vai te perguntar “e se o usuário puxar o cabo de rede no meio do download do modelo?”. Mas se você perguntar, ele implementa o tratamento em minutos.

É tentador olhar pra esse projeto e concluir que qualquer pessoa com uma boa ideia poderia ter feito o mesmo. Mas tente imaginar: sem a decisão de fazer benchmarks, eu teria escolhido o modelo errado. Sem o PoC em Python, teria descoberto os problemas de JSON parsing em produção. Sem a abstração de plataforma, estaria debugando issues de Windows espalhadas por 15 arquivos. Sem o checkpoint de scan, usuários perderiam horas de processamento a cada crash. Sem a migração formal de schema, a primeira atualização quebraria o banco de todo mundo.

Pense num arquiteto com uma equipe de construção absurdamente eficiente. O arquiteto não precisa levantar cada parede, mas precisa saber onde elas vão e o que acontece se você tirar uma. A equipe executa rápido, trabalha de noite, não reclama. Mas alguém precisa ter desenhado a planta. Sem planta, é só um monte de tijolos empilhados rápido.

Números Finais

Pra quem gosta de números concretos:

O primeiro commit foi sexta-feira 21/02 às 19:29. O último foi segunda-feira 23/02 às 14:33. Descontando sono (~8h na noite de sábado/domingo, ~8h na madrugada de domingo/segunda) e pausas, são ~26 horas de trabalho distribuídas em um fim de semana.

De zero — sem um único arquivo no repositório — a binários publicados para 3 sistemas operacionais, com testes automatizados rodando no CI a cada push. Incluindo a fase de pesquisa, que sozinha justificaria um sprint.

Conclusão

Agile Vibe coding funciona. Mas funciona como qualquer ferramenta poderosa: nas mãos de quem sabe o que está fazendo.

A ideia do Frank Sherlock caberia num tweet: “classificar imagens com LLM local”. Mas transformar isso em software real exigiu: pesquisa benchmarked com ground truth formal, prova de conceito validando o pipeline completo, arquitetura incremental, tratamento de erros em 3 níveis, cancelamento cooperativo, migração formal de schema, abstração de plataforma, CI/CD com matrix de 3 OS, integração com 3 sistemas externos com graceful degradation, e 338 testes pra garantir que nada disso quebra quando alguém fizer cargo update.

O LLM acelerou tudo isso absurdamente. Mas não substituiu a necessidade de saber o que fazer. Se eu tivesse pedido “faz um app que classifica imagens” sem as 2 horas de benchmark, sem a prova de conceito, sem as decisões de arquitetura, sem as perguntas chatas sobre edge cases, o resultado seria um protótipo que funciona na minha máquina e quebra em qualquer outro lugar. E provavelmente eu nem perceberia até alguém reclamar.

O vibe precisa de um condutor experiente. Por enquanto, esse condutor ainda é humano.

Código em github.com/akitaonrails/FrankSherlock. GPL-3.0, local-only, open source.

Então fiz o que qualquer programador faria: sentei, escrevi um documento de especificação, e com ajuda do Claude Code (Claude Opus 4.6), construí o FrankMega, um clone simplificado do Mega, self-hosted, em Rails 8, em um único dia de trabalho. 21 commits, 3 horas de desenvolvimento ativo, 210 testes, zero dependência externa além do SQLite.

E antes que apareça o esperto nos comentários: “ah, mas Vibe Coding é só prompt engineering, qualquer um faz” – calma. Esse post é justamente pra mostrar que não é.

Da Ideia ao Código: o IDEA.md

Todo projeto começa com um documento. O meu foi o docs/IDEA.md – 56 linhas descrevendo o que eu queria:

• Upload de arquivo único, com link compartilhável
• Contador de downloads (padrão 5, configurável)
• Expiração automática em até 24 horas
• Autenticação completa: senha + 2FA + passkeys
• Sem página de registro público – convites only
• Admin cria convites, gerencia usuários, bane abusadores
• Rate limiting agressivo, IP banning automático
• Deploy via Docker + Cloudflare Tunnel no meu home server
• Stack: Rails 8, SQLite, Tailwind CSS, Hotwire/Stimulus

Eu deliberadamente incluí no final: “Sugira features importantes que possam ser relevantes pra um serviço assim.” Porque eu sei que um documento de spec nunca cobre tudo. E é aí que começa a parte interessante.

O Big Bang: Commit #1

O primeiro commit (e277226) às 12:17 entregou 207 arquivos, 6.901 linhas de código. Num único commit. Sim, eu sei que é controverso, mas quando se está construindo do zero com AI, o primeiro commit é necessariamente grande.

O que veio nesse commit inicial:

• Autenticação completa com has_secure_password (bcrypt), TOTP via rotp, passkeys via webauthn
• Sistema de convites com códigos únicos e expiração
• Admin panel completo (Users, Invitations, Files, MIME Types)
• Upload com Active Storage + drag-and-drop via Stimulus
• Links de download com hashes de 24 bytes (SecureRandom.urlsafe_base64(24))
• Rate limiting via Rack::Attack em todos os endpoints públicos
• IP banning automático com modelo Ban e job assíncrono
• Tema dark/light com Tailwind CSS inspirado no Mega.nz
• 73 testes (Minitest + FactoryBot)
• Docker configuration com Puma + Thruster
• Solid Queue/Cache/Cable – zero Redis

Entenderam? Tudo isso no commit #1. O IDEA.md virou código funcional numa tacada. Mas o ponto é esse: o primeiro commit não era production-ready. Nem de longe.

A Realidade: 20 Commits de Iteração

Depois do Big Bang vieram 20 commits ao longo de 3 horas. E é aqui que mora a verdade sobre desenvolvimento de software que nenhum tutorial de “Vibe Coding” vai te contar.

Fase 1: “Funciona na minha máquina” (12:40 - 12:46)

Quatro commits em 6 minutos. Sabe o que aconteceu? Fui buildar o Docker e quebrou. Faltava libssl-dev. Consertei. Daí o CSP (Content Security Policy) do secure_headers conflitava com os inline scripts do importmap do Rails. Consertei. Mudei a porta de 3000 pra 3100 pra não conflitar com outros serviços no meu server.

Olha o commit 389ebe8:

# CSP agora é feito pelo Rails built-in, não pelo secure_headers
# Porque secure_headers não suporta nonces pra importmap inline scripts
config.csp = SecureHeaders::OPT_OUT

Esse tipo de incompatibilidade entre gems você só descobre na hora. Nenhum LLM vai te avisar disso de antemão porque é uma combinação específica de versões.

Fase 2: O Commit de Segurança – 22 Falhas Corrigidas (13:10)

Esse é o commit mais importante do projeto inteiro: 4a854a6. 35 arquivos, 612 linhas, 22 issues de segurança corrigidas. Vou detalhar porque é aqui que se separa código de brinquedo de código de produção.

O que o commit inicial fazia de errado:

CRÍTICO – Chaves de criptografia com fallback hardcoded:

# ANTES (perigoso):
config.active_record.encryption.primary_key = ENV.fetch("KEY", "test-primary-key")

# DEPOIS (fail-fast):
if Rails.env.production?
  config.active_record.encryption.primary_key = ENV.fetch("ACTIVE_RECORD_ENCRYPTION_PRIMARY_KEY")
end

Se o ENV var não existisse em produção, a app rodava feliz com a chave hardcoded. Qualquer pessoa que lesse o código-fonte conseguiria decriptar os segredos OTP de todos os usuários. Agora em produção, se faltar a variável, a app crasheia no boot. É o comportamento correto.

CRÍTICO – Replay Attack no OTP:

# ANTES:
def verify_otp(code)
  totp = ROTP::TOTP.new(otp_secret)
  totp.verify(code, drift_behind: 30, drift_ahead: 30).present?
end

# DEPOIS:
def verify_otp(code)
  totp = ROTP::TOTP.new(otp_secret)
  timestamp = totp.verify(code, drift_behind: 30, drift_ahead: 30)
  return false unless timestamp

  # Previne replay: rejeita se o timestamp desse código já foi usado
  if last_otp_at.present? && Time.at(timestamp) <= last_otp_at
    return false
  end

  update_column(:last_otp_at, Time.at(timestamp))
  true
end

Todo tutorial de TOTP que você encontra na internet mostra o verify(code).present? e para aí. O problema: um código TOTP é válido por 30 segundos. Se eu interceptar seu código (shoulder surfing, câmera, clipboard), posso usá-lo múltiplas vezes nessa janela. O last_otp_at garante one-time use real.

ALTO – Race Condition no Download Counter:

# ANTES (race condition):
def increment_download!
  increment!(:download_count)
end

# DEPOIS (atômico):
def increment_download!
  self.class.where(id: id)
      .where("download_count < max_downloads")
      .where("expires_at > ?", Time.current)
      .update_all("download_count = download_count + 1") == 1
end

O increment! faz: (1) lê o valor, (2) soma 1 em Ruby, (3) escreve de volta. Duas requisições simultâneas podem ler 4, ambas escreverem 5, e o usuário ganha dois downloads quando só tinha um. O UPDATE ... WHERE atômico no SQL garante que só uma requisição vence. E o == 1 retorna sucesso/falha numa única operação, sem lock.

Isso é o clássico bug TOCTOU (Time of Check, Time of Use). Você nunca vai ver isso no desenvolvimento local com um browser. Só aparece em produção com requisições concorrentes.

ALTO – Open Redirect após login:

# DEPOIS:
def safe_redirect_url?(url)
  uri = URI.parse(url)
  uri.host.nil? || uri.host == request.host
rescue URI::InvalidURIError
  false
end

Sem isso, um atacante podia enviar um link tipo frankmega.com/session?return_to=https://evil.com e após login o usuário seria redirecionado pro site malicioso.

MÉDIO – Nonce do CSP previsível:

# ANTES:
config.content_security_policy_nonce_generator = ->(request) { request.session.id.to_s }

# DEPOIS:
config.content_security_policy_nonce_generator = ->(_request) { SecureRandom.base64(16) }

Session ID não muda entre requests. Se o nonce é previsível, um atacante pode injetar scripts com o nonce correto. Tem que ser aleatório por request.

E mais: IPv6 do Cloudflare adicionado aos trusted proxies, mínimo de 12 caracteres pra senha, MIME detection server-side via Marcel, verificação de file size pelo tempfile (não pelo header do client que pode ser forjado), proteção contra deletar/banir/rebaixar o último admin.

O total de testes pulou de 73 pra 109 com esse único commit.

Como Rails Facilita Segurança

Rails torna MUITO mais fácil implementar segurança do que fazer do zero. Olha a comparação:

O Rails 8 em particular trouxe o rate_limit built-in no controller:

class SessionsController < ApplicationController
  rate_limit to: 10, within: 3.minutes, only: :create,
    with: -> { redirect_to new_session_path, alert: t("flash.sessions.create.rate_limit") }
end

E a autenticação? Rails 8 agora vem com um authentication generator built-in. Não precisa mais do Devise pra coisas básicas. O app/controllers/concerns/authentication.rb do FrankMega é baseado nisso e estende com 2FA, passkeys e invitation-only registration.

File Sharing Não É Só Download

Uma coisa que muita gente não percebe: um serviço de file sharing tem uma superfície de ataque enorme. Não é só “salvar arquivo, gerar link”. Olha tudo que precisa ser considerado:

Sanitização de Filename

def sanitize_filename(name, content_type = nil)
  sanitized = File.basename(name.to_s)                          # Strip path traversal
  sanitized = sanitized.encode("UTF-8", invalid: :replace,      # Handle invalid UTF-8
                                undef: :replace, replace: "")
  sanitized = sanitized.gsub(/[\x00-\x1f\x7f\/\\:*?"<>|]/, "") # Control chars + unsafe chars
  sanitized = sanitized.sub(/\A\.+/, "")                        # Leading dots (hidden files)
  sanitized = sanitized.gsub(/\s+/, " ").strip                  # Collapse whitespace

  # Windows reserved device names
  base_without_ext = sanitized.sub(/\.[^.]*\z/, "")
  if base_without_ext.match?(/\A(CON|PRN|AUX|NUL|COM[1-9]|LPT[1-9])\z/i)
    sanitized = "_#{sanitized}"
  end

  sanitized = strip_extension_junk(sanitized, content_type)
  sanitized = truncate_filename(sanitized, 255)
  sanitized.presence || "unnamed_file"
end

Cada linha existe por um motivo:

• File.basename impede path traversal (../../etc/passwd vira passwd)
• Strip de control chars impede null byte injection e terminal escape injection
• Nomes reservados do Windows (CON, NUL, AUX, LPT1-9) causam problemas se o storage for acessado de um Windows
• Truncamento pra 255 bytes (não caracteres!) preservando a extensão – um emoji de 4 bytes conta como 4 pro limite do ext4/NTFS
• strip_extension_junk trata nomes que vêm de URLs com parâmetros grudados: photo.jpg_1280x720+quality=80 vira photo.jpg

E isso é server-side. Tem validação client-side também no Stimulus controller pra rejeitar antes do upload:

isInvalidFilename(name) {
  if (new Blob([name]).size > 255) return true
  if (/[\x00-\x1f\x7f/:*?"<>|\\]/.test(name)) return true
  return false
}

MIME Type Detection Server-Side

@shared_file.content_type = Marcel::MimeType.for(uploaded.tempfile, name: uploaded.original_filename)
@shared_file.file_size = uploaded.tempfile.size

Não confia no Content-Type que o browser envia. O Marcel inspeciona os magic bytes do arquivo pra determinar o tipo real. E o file size vem do tempfile no disco, não do header Content-Length que pode ser forjado.

Quotas e Disk Usage

Cada usuário tem uma quota de disco (5 GB default, admin pode customizar):

def can_upload?(file_size)
  grace = Rails.application.config.x.security.disk_quota_grace_bytes
  (storage_used + file_size) <= (disk_quota + grace)
end

Sem quota, um único usuário malicioso enche o disco do servidor. Com o grace buffer de 10%, um upload que passa um pouco do limite é aceito pra não frustrar o usuário no edge case.

Cleanup Automático

class CleanupExpiredFilesJob < ApplicationJob
  queue_as :default

  def perform
    SharedFile.inactive.find_each do |shared_file|
      shared_file.file.purge if shared_file.file.attached?
      shared_file.destroy
    end
  end
end

Roda a cada 15 minutos via Solid Queue. Se ninguém baixou em 24 horas, sumiu. Se bateu o limite de downloads, sumiu. Sem isso, disco do servidor enche e o serviço morre.

IP Banning Automático

class InvalidHashAccessJob < ApplicationJob
  queue_as :default

  def perform(ip_address)
    security = Rails.application.config.x.security
    return unless security.enable_banning

    cache_key = "invalid_hash:#{ip_address}"
    count = Rails.cache.increment(cache_key, 1, expires_in: 1.hour) || 1

    if count >= security.max_invalid_hash_attempts
      Ban.ban!(ip_address, reason: "Repeated invalid download hash access",
               duration: security.ban_duration)
      Rails.cache.delete(cache_key)
    end
  end
end

Tentou 3 hashes inválidos? Banido por 1 hora. Isso impede enumeração de hashes. Com 24 bytes de entropia (192 bits, 2^192 possibilidades), brute force é computacionalmente inviável, mas a proteção extra não custa nada.

Rate Limiting em Camadas

O Rack::Attack opera na camada de middleware (antes do Rails processar):

# Login: 5 tentativas por minuto por IP
Rack::Attack.throttle("logins/ip", limit: 5, period: 1.minute) do |req|
  req.ip if req.path == "/session" && req.post?
end

# Login: 5 tentativas por minuto por email
Rack::Attack.throttle("logins/email", limit: 5, period: 1.minute) do |req|
  if req.path == "/session" && req.post?
    req.params.dig("email_address")&.to_s&.downcase&.strip
  end
end

# Downloads: 60 views e 30 downloads por minuto
Rack::Attack.throttle("downloads_get/ip", limit: 60, period: 1.minute) do |req|
  req.ip if req.path.start_with?("/d/") && req.get?
end

# Geral: 300 requests por 5 minutos (exceto assets)
Rack::Attack.throttle("requests/ip", limit: 300, period: 5.minutes) do |req|
  req.ip unless req.path.start_with?("/assets")
end

Sete throttles diferentes pra cenários específicos. Mais o rate_limit do Rails 8 nos controllers. IPs banidos nem chegam ao Rails – são rejeitados na blocklist do middleware com status 403.

E os limites são configuráveis: em produção é 1x, em desenvolvimento é 10x pra não se trancar durante testes. Tudo centralizado no config/initializers/security.rb.

A Saga do Download: 5 Commits em 21 Minutos

Essa parte é divertida porque mostra debugging real. Entre 14:44 e 15:05, eu fiz 5 commits tentando fazer o download funcionar com Turbo Drive:

1. cc3c23d – Adicionei data-turbo=false no botão de download. Não funcionou.
2. 5224ed2 – Movi data-turbo=false pro <form>. Não funcionou.
3. 98b0d4f – Abandonei o redirect_to rails_blob_path e usei send_file direto. Parcialmente funcionou.
4. 1fdf5f9 – Troquei de POST pra GET link. Funcionou mas… bots podem consumir downloads com GET.
5. 4c74b27 – Voltei pra POST. Adicionei cleanup de URL artifacts nos filenames.

O root cause: o Turbo Drive intercepta navegação agressivamente, e download de arquivo via redirect_to (que gera uma cadeia de 302 redirects do Active Storage) confunde o Turbo. A solução final: send_file direto do disco com disposition: "attachment" via POST com data: { turbo: false } no form.

Esse tipo de problema um LLM não resolve sozinho. Precisa testar no browser real, ver o que acontece, tentar, falhar, ajustar. É desenvolvimento iterativo puro.

O Gap entre a Ideia e o Produto Final

Olha o que o IDEA.md não mencionava e que emergiu durante o desenvolvimento:

1. Per-user disk quotas – sem isso um usuário enche o disco do server
2. I18n completo (EN + PT-BR) – 66 arquivos, ~250 strings extraídas
3. Terms of Service com aceite obrigatório
4. User self-deletion – requisito de privacidade
5. Blocked downloads de usuários banidos – seus links retornam 410 Gone
6. Client-side upload validation – verifica size, quota e filename antes do upload
7. Inline file previews – imagens, vídeo e áudio no download page sem consumir downloads
8. Styled error pages – em vez de plain text “Not Found”, páginas branded com i18n

O IDEA.md dizia “use activeadmin ou administrate”. Na prática construí um admin panel custom com Tailwind porque o administrate tinha problemas de compatibilidade com Rails 8.1. O IDEA.md falava em “progress bar se possível”. Na prática usei drag-and-drop com preview de arquivo via Stimulus, que é melhor que progress bar.

Ninguém consegue prever todas as features no dia 1. Você descobre requisitos conforme constrói. E cada feature nova traz edge cases que precisam ser tratados.

Os Números

Ao final do projeto:

• 21 commits em uma sessão de ~3 horas
• 210 testes (Minitest + FactoryBot), 513 assertions, zero failures
• ~3.100 linhas de código de aplicação (models, controllers, views, JS, CSS, configs)
• ~1.965 linhas de testes (incluindo testes de segurança dedicados)
• 9 models, 20 controllers, 36 views, 9 Stimulus controllers
• 24 medidas de segurança distintas em 7 camadas
• CI: SimpleCov, RuboCop (zero offenses), Brakeman (zero warnings), bundler-audit (zero vulnerabilities)
• Zero dependências externas além do SQLite. Sem Redis, sem PostgreSQL, sem serviço de fila externo

O Invitation-Only Server

O FrankMega não tem cadastro público. O fluxo é:

1. Na primeira execução, sem nenhum usuário, aparece a tela de setup pra criar o admin
2. A rota /setup só existe enquanto User.count.zero? – depois some completamente:

constraints(->(request) { User.count.zero? }) do
  get "setup", to: "setup#new"
  post "setup", to: "setup#create"
end

3. O admin cria convites no painel admin (com expiração)
4. Cada convite gera um código único de 16 bytes
5. Cada código só pode ser usado uma vez (with_lock + transaction pra impedir race condition)
6. Após cadastrar, o convite é marcado como “used”

Isso é perfeito pra um serviço pessoal/familiar. Controle total de quem acessa.

Deploy: Docker + Cloudflare Tunnel

Pra fechar, o tutorial de deploy, caso queira rodar no seu próprio Home Server Docker. Não é complicado mas tem detalhes que importam.

O Dockerfile

Multi-stage build em 3 estágios:

# Stage 1: Base (runtime)
FROM ruby:3.4.8-slim AS base
RUN apt-get install -y curl libjemalloc2 libvips sqlite3
# jemalloc pra melhor gerenciamento de memória

# Stage 2: Build (throwaway)
FROM base AS build
RUN apt-get install -y build-essential git libssl-dev
# Bundle install + asset precompilation com dummy env vars

# Stage 3: Final
# Copia gems e app, roda como user não-root (rails:rails, UID 1000)
CMD ["./bin/thrust", "./bin/rails", "server"]

O bin/thrust é o Thruster (do Basecamp) – um proxy HTTP na frente do Puma que faz: gzip/brotli compression, asset caching, X-Sendfile acceleration. Escuta na porta 80, proxeia pro Puma na 3000.

O entrypoint roda db:prepare e db:seed automaticamente no boot:

#!/bin/bash -e
if [ "${@: -2:1}" == "./bin/rails" ] && [ "${@: -1:1}" == "server" ]; then
  ./bin/rails db:prepare
  ./bin/rails db:seed
fi
exec "${@}"

docker-compose.yml

Dois serviços:

services:
  web:
    image: akitaonrails/frankmega:latest
    ports:
      - "3100:80"
    volumes:
      - /home/seuuser/frankmega/uploads:/rails/storage/uploads
      - /home/seuuser/frankmega/db:/rails/storage
    environment:
      SECRET_KEY_BASE: ${SECRET_KEY_BASE}
      HOST: ${HOST}
      # ... mais ~15 variáveis
    restart: unless-stopped

  tunnel:
    image: cloudflare/cloudflared:latest
    command: tunnel run
    environment:
      - TUNNEL_TOKEN=${TUNNEL_TOKEN}
    depends_on:
      - web
    restart: unless-stopped

O sidecar cloudflare/cloudflared cria um túnel outbound pra edge do Cloudflare. Não precisa abrir portas no firewall do home server. O Cloudflare faz SSL termination, DDoS protection, e roteia o tráfego pro container.

Passo a Passo

1. Crie o Tunnel no Cloudflare:

• Cloudflare Zero Trust Dashboard > Networks > Tunnels > Create
• Tipo: Cloudflared
• Copie o TUNNEL_TOKEN
• Configure o hostname: frankmega.seudominio.com apontando pra http://web:80

2. Gere os segredos:

# SECRET_KEY_BASE
openssl rand -hex 64

# Chaves de criptografia (3 valores separados)
openssl rand -hex 32  # PRIMARY_KEY
openssl rand -hex 32  # DETERMINISTIC_KEY
openssl rand -hex 32  # KEY_DERIVATION_SALT

3. Configure o .env:

SECRET_KEY_BASE=<gerado acima>
RAILS_MASTER_KEY=<do config/master.key>
HOST=frankmega.seudominio.com
WEBAUTHN_ORIGIN=https://frankmega.seudominio.com
WEBAUTHN_RP_ID=frankmega.seudominio.com
ACTIVE_RECORD_ENCRYPTION_PRIMARY_KEY=<gerado>
ACTIVE_RECORD_ENCRYPTION_DETERMINISTIC_KEY=<gerado>
ACTIVE_RECORD_ENCRYPTION_KEY_DERIVATION_SALT=<gerado>
TUNNEL_TOKEN=<do Cloudflare>
FORCE_SSL=true
APP_LOCALE=pt-BR

4. Suba:

docker compose pull
docker compose up -d

5. Acesse https://frankmega.seudominio.com, crie a conta admin, comece a usar.

Cuidados Importantes

• FORCE_SSL=false pra testar localmente em http://localhost:3100 sem Cloudflare na frente, senão entra em redirect loop
• WebAuthn origin precisa bater exatamente, incluindo o https://. Se errar, passkeys silenciosamente não funcionam
• IPs do Cloudflare são hardcoded no initializer (porque o gem cloudflare-rails não é compatível com Rails 8.1). Se o Cloudflare mudar os ranges, precisa rebuildar a imagem
• Chaves de criptografia são permanentes. Se trocar depois que usuários configuraram 2FA, os segredos OTP ficam ilegíveis e eles perdem acesso
• Cloudflare free tem limite de 100 MB de upload. Pro plano grátis, arquivos acima disso não passam pelo tunnel. A app permite até 1 GB mas o Cloudflare é o gargalo
• O container roda como UID 1000. Se usar bind mounts ao invés de named volumes, o diretório precisa ser owned pelo UID 1000
• São 4 bancos SQLite separados em produção (app, cache, queue, cable), todos no volume db_data. Backup é copiar o volume inteiro

O Verdadeiro Ponto Sobre “Vibe Coding”

O Claude Code é absurdamente produtivo. Eu não teria feito tudo isso em 3 horas sem ele. Lembra de antigamente que você dava murro em ponta de faca por 1 semana só pra fazer um login funcionar? Pois é.

O commit de I18n sozinho (66 arquivos, ~250 strings extraídas pra dois idiomas) levaria um dia inteiro manualmente.

Mas o ponto que ninguém quer ouvir: o LLM não tomou as decisões de segurança. Eu pedi pra ele fazer um audit e ele encontrou os problemas, mas eu precisei saber pedir. E precisei saber quais perguntas fazer. “Revise a segurança” é uma instrução vaga. “Verifique se tem race condition no increment do download counter” é uma instrução que só quem sabe o que é TOCTOU consegue dar.

Aquelas 56 linhas do IDEA.md carregam décadas de experiência em desenvolvimento web. Eu sabia pedir rate limiting porque já vi serviços derrubados por bots. Sabia pedir IP banning porque já lidei com abuse. Sabia pedir download counter atômico porque entendo concorrência.

Se um iniciante escrevesse o mesmo IDEA.md, provavelmente não teria metade dessas preocupações. E o LLM não iria sugerir espontaneamente. O resultado seria um serviço funcional, bonito, e completamente inseguro.

O valor do programador experiente no Vibe Coding não é escrever código. É saber o que pedir e revisar o que foi gerado. A experiência é o filtro entre “funciona” e “funciona em produção”.

Os 210 testes e 24 medidas de segurança não vieram de prompt engineering. Vieram de saber o que testar e por quê.

O código é open source sob AGPL-3.0: github.com/akitaonrails/frank_mega. Deploy no seu server, fucem o código, aprendam com os commits. E se acharem mais falhas de segurança, me avisem.

Lembrem-se:

A IA é o espelho da sua própria competência.

–

No dia 10 de fevereiro de 2026, eu postei o tweet acima, só jogando no ar uma coisa que estava na minha to-do list há anos, desde que eu publicava vídeos no YouTube. Nunca fiz porque eu odeio HTML/CSS e ter que fazer template de e-mail era suficiente pra não começar. Além disso, fazer mais uma newsletter, que é só uma lista de links chata, não me motivava.

Mas nesse dia eu já estava terminando meu segundo projeto com vibe coding, o FrankMD, e acho que entendi os principais truques e a metodologia pra fazer um produto completo da forma certa. Então, começaram a surgir várias ideias. Dei dump e escrevi este pequeno documento.

Pensei: e se eu fizesse não só o código do sistema de newsletter com vibe code, mas também tivesse parte do próprio conteúdo gerada por IA de forma inusitada, em forma de comentaristas: eu e um robô? E, claro, com Guia do Mochileiro na mente, tinha que ser o MARVIN, ou melhor, o “M.Arvin” (pra ninguém encher com copyright).

É claro, vai ter versão por e-mail semanal e um blog de arquivos. Mas já que vai ter tudo isso, por que não reescrever já toda a newsletter em script de podcast? E já que recentemente saiu o Qwen3 TTS, open source, por que não treinar um LoRa com minha voz (obviamente, tenho centenas de horas de minha voz no YouTube) e fazer um podcast totalmente automatizado?

Finalmente, um dos desmotivadores pra mim seria criar um Web Admin tradicional e ter que entrar manualmente lá pra cadastrar os links de notícias e meus comentários. Eu sei que ia me dar preguiça e, a uma hora, ia cansar. Só tinha uma solução: criar um bot mais inteligente com o qual eu pudesse conversar via DISCORD. Assim, eu posso rapidamente acessar, seja do meu PC, seja do meu smartphone, sem precisar logar num sistema separado nem nada. Eu já converso com pessoas no Discord, então a fricção seria zero.

Então:

• Marvin Bot pra gerenciar todo conteúdo (que eu mando e os automatizados, com comentários e tudo mais)
• Monitor de X.com pra checar o que eu postei e já pegar pra usar na newsletter. Incluindo as replies que eu dou, que vão virar Q&A!
• Newsletter website pra assinar, cancelar, etc
• Blog pra arquivos de newsletter e de transcripts dos podcasts (também com termos de serviço e de privacidade — sim, sou LGPD compliant!)
• Gerador automático de vozes e montador de podcast que vai subir automaticamente pra deixar disponível pro Spotify
• E ainda templates de blog e de e-mail, com versões de tema light e dark.

Você, que é um programador experiente, sem IA, quanto tempo levaria pra fazer tudo isso?

Pois bem, eu comecei no dia 10 de fevereiro. Terminei tudo no domingo, dia 15 de fevereiro. E hoje, dia 16, rodaram os jobs de produção pela primeira vez, o que gerou newsletter, blog posts, podcast, upload pro Spotify, envio de email.

E não foi do jeito podre que todo vibe coder amador faz:

Quem é de Rails deve ter ficado surpreso: projeto com taxa de 1 pra 1 de testes! 1 linha de testes pra cada 1 linha de código: 100% de cobertura. E isso, sem contar um projeto separado deles de integração completa, ponta a ponta (que usei pra garantir que a produção ficaria perfeita).

Todas as estratégias que eu aprendi ao longo dos anos colocando projeto em produção: segurança, escalabilidade, durabilidade, garantia de entrega sem spammar duplicatas de e-mails, etc. Depois vejo se faço mais posts específicos sobre alguns dos truques técnicos.

Este projeto não vou abrir como open source. Eu fiz 100% customizado pra mim, pro meu fluxo de trabalho e meus estilos. Não é difícil pra outro programador competente fazer a mesma coisa com vibe code: se eu consegui, qualquer um consegue. Então é só não ter preguiça de pensar e fazer. Aliás, não entendo como tech youtubers ainda não estão lançando 1 projeto completo em produção, por vídeo, pra todo mundo testar e ver.

No screenshot também não está o servidor de Qwen3-TTS, que produz áudio. Esse é bem mais simples, um servidor PyTorch. Aqui foi Python mesmo. O mais importante é o fine tuning do modelo pra gerar vozes exatamente do jeito que eu queria:

O blog é todo com Hugo/Hextra, como este também. E meu bot publica lá automaticamente.

M.Arvin Bot

O M.Arvin tem uma personalidade que eu detalhei como eu queria. E é um bot de Discord, então meu trabalho é assim:

Só preciso mandar um link com meu comentário (igual eu faria no X.com), ou posso postar direto no X, que ele vai pegar igual. Daí ele busca o conteúdo, faz um resuminho, faz um pequeno fact-check e o M.Arvin gera seu comentário em cima do meu.

Eu programei ele pra responder a um monte de comandos pra facilitar meu dia a dia. Isso é só uma pequena parte:

Eis um exemplo: eu tenho controle sobre quanto de IA ele está usando (é bem barato):

Deployment

Neste post não vou detalhar muito, mas uma coisa em que demorei bastante, passando por várias discussões e versões com o Claude Code, foi na arquitetura de infraestrutura. E no final ele conseguiu me dar um Deployment Guide, que consegui seguir até o fim e sabendo que minimamente está como eu mesmo faria se tivesse feito tudo sozinho:

Nenhum software tem garantia de ser 100% perfeito; este também não deve ser. Mesmo eu tendo revisado por dias, passando por cada etapa várias vezes, sempre vai ter algum bug que eu não previ. Eu “acho” que, pelo menos, tudo o que sei que costuma dar problema em produção, “acho” que consegui cobrir de forma satisfatória. Se fosse uma equipe humana, eu teria colocado em produção num estado pior do que o que atingi com o Claude.

Tudo o que dava pra proteger com Cloudflare, eu configurei. Todas as boas práticas pra e-mail/mailing, eu segui. Todas as precauções contra acidentes eu tomei (todo deploy automatizado com Kamal) e todos os e-mails dos assinantes foram encriptados com AES-256 no banco de dados (mesmo que vazem por acidente, não vazam os dados dos usuários). Não implementei profiling, cookies nem pixels de rastreamento, nada. Privacidade foi o foco.

Tudo o que dava pra reduzir custos, eu reduzi; afinal, vou pagar do meu bolso. Então, coisas como GPU na RunPod pra gerar os áudios são serverless. Eu subo só no momento de gerar; ele faz todo o processo e, depois, a máquina desliga. O servidor está todo organizado numa imagem Docker leve. Todos os modelos de IA estão num volume de rede separado.

Spoiler do Processo

Depois pretendo fazer um post maior falando da minha metodologia, mas é muito simples: trate o Claude Code/Codex como se fosse um programador humano esforçado — que vai cometer muitos erros, mas sabe obedecer ordens super explícitas, diretas, claras e sem ambiguidade. Meu papel é de gerente de produto, Tech Lead ou QA. Têm que ser os TRÊS papéis.

No total, o Claude Code fez 201 commits. Mas não são commits normais; considero que, num projeto normal com humanos, cada um teria feito aproximadamente 150 Pull Requests.

Pergunta a vocês que participam de sprints em projetos: quanto tempo leva pra ter 150 user stories/bug fixes aprovados e em produção no seu projeto real? Quantos user stories vocês conseguem fazer e aprovar (com QA e tudo) em UMA semana?

Eis um exemplo de um commit/“user story”:

Quando estava lá no commit, talvez 50, eu já pensava: “Já funciona!”* É o estágio que todo criador de conteúdo (que nunca colocou projetos de verdade em produção) já postaria, dizendo: “fiz vibe code em 2 dias”. De fato, em 2 dias eu já tinha o grosso das funcionalidades prontas.

Os outros 4 dias foram:

• 1 dia pra deploy em produção (quando tem tudo planejado com antecedência, todas as contingências já pensadas, é fácil).
• 3 dias só testando, criando testes automatizados/integração, gerando e regerando, exercitando todas as etapas de todas as partes, múltiplas vezes, e fazendo ajustes, refatorações ou até mesmo jogando fora um pedaço inteiro pra mudar, porque os testes indicaram que valia mais a pena.

Isso levou de 50 a 200 commits! E é a parte que todo vibe coder pula. Pra ser justo, é a parte que qualquer pessoa, com ou sem IA, pularia. E é por isso que sempre os projetos dão errado e vão pra produção cheios de erros e de buracos óbvios de segurança.

Mesmo depois de pedir ao Claude Code pra revisar boas práticas de segurança e de cobertura de testes, múltiplas vezes. Depois eu abri o Codex e pedi pra fazer a mesma coisa, e ele ainda achou mais buracos de segurança e mais testes faltando, múltiplas vezes. Mesmo depois dos dois fazerem essas checagens várias vezes, eu ainda encontrei sozinho mais buracos que mandei consertar. Em nenhum momento, nenhum dos dois conseguiu achar “TUDO”. Ninguém consegue, nem a IA.

Conclusão

Programar Vibe Coding da forma correta só tem um jeito: Extreme Programming!

Sim, todas as coisas “chatas” e “burocráticas” que todo desenvolvedor odeia fazer são o que garante que a IA vai devolver um resultado aceitável pra colocar em produção:

• Pair Programming: você precisa mandar a IA planejar primeiro e te dizer exatamente tudo o que vai fazer, ANTES de começar. Eu reviso, ajusto e, só quando estou satisfeito, deixo fazer. Fico olhando cada coisa que ele faz e, no final, mando ajustar o que acho que faltou.
• Test-Driven Development: toda funcionalidade deve vir acompanhada de testes unitários. Toda correção de bug precisa de testes de regressão.
• Continuous Integration: Toda vez que termina de implementar, precisa rodar script de CI pra ver se nada quebrou em outro lugar. Mais do que isso: no branch master, só há commits com testes que passam. Eu posso reverter em qualquer ponto e o projeto roda.
• Small Releases: isso eu achei ótimo no Claude, mesmo se eu acabar esquecendo de mandar ele comitar uma tarefa e mandar fazer outra, no fim, ele não faz aquela tosquice de git add . — não: ele separa em 2 commits e descreve cada um da forma correta. Além disso, eu subi produção na sexta-feira, e continuei sábado e domingo testando integração local e em ambiente de produção, pra garantir que não tem isso de “só na minha máquina funciona”
• Coding Standard: eu iniciei com o mínimo de requerimentos técnicos, mas, durante o desenvolvimento, mandei refatorar do meu jeito várias e várias vezes.

Essas são as principais tarefas a serem feitas. Já adianto: “Spec Driven Development” não é totalmente inútil, mas a estrutura não tem importância: é o seu texto que conta.

É a mesma coisa que User Stories. Grande bosta que você escreveu “Eu, como o usuário final, Quero que quando digitar X …, o sistema responda com Y”. O formato NUNCA é importante. O que é importante é COMO você escreveu o que vai no meio. Se você não sabe escrever, a IA não vai saber responder a você como deveria. Vou fazer outro artigo só pra demonstrar como todos vocês são péssimos em escrever.

O recado é simples: Vibe Code funciona, em partes.

O que funciona mesmo é “Senior Agile Vibe Coder”

Vou perguntar de novo: quanto tempo, sem IA, você levaria pra produzir 150 user stories/bug fixes, no escopo que resumi no começo? Até colocar em produção com tudo testado? Duvido que seja em 6 dias como eu fiz.

“Eu, como um total zero à esquerda em programação, quero fazer um app perfeito, seguro, de qualidade, somente com prompts. Qual LLM vai me atender?”

A minha resposta de 2 anos atrás e até agora continua sendo:

NENHUMA!

Ontem eu fiz um LONGO artigo onde eu DEMONSTRO como é fazer um appzinho do zero somente com Vibe Coding. Um escopo menor que um exercício de “to-do list”.

Pra “fazer funcionar” foi fácil: em 1 hora eu tinha o app. O tal “zero à esquerda” acima, pararia aqui.

Mas pra fazer um código de qualidade, seguro, otimizado, testado, etc, me custou as próximas 12 horas e mais de 250 prompts e intervenções manuais.

Quando postei, alguns ainda vieram “Ah, mas você usou GLM, se tivesse usado Claude Code ou Codex, teria sido mil vezes melhor.”

Ok, engoli o bait.

Hoje eu passei mais umas boas 2 horas em cima do código final do GLM e fiz o seguinte:

• Mandei o Claude Code fazer uma análise EXTENSIVA de segurança, otimização, testes, etc e ele saiu com este commit

• Em cima disso que o Opus corrigiu, pedi pro GPT 5.2 Codex fazer a mesma análise EXTENSIVA. E ele saiu com este commit

• Não satisfeito, e vendo que acabou de sair o Kimi 2.5, pedi a ele pra fazer a mesma análise EXTENSIVA. E ele saiu com este commit

• Mas pra garantir mesmo, a seguir pedi ao Gemini 3.0 Preview a mesma análise EXTENSIVA. E ele saiu com este commit

• Não resisti e quis terminar mandando o MiniMax v2.1 também participar fazendo a mesma análise EXTENSIVA. E ele saiu com este commit

Estão entendendo??? LET THAT FUC–NG SINK IN!!

NENHUM é capaz de fazer um appzinho menor que um to-do list da forma perfeita. Isso não existe.

A única coisa que existe são seus requerimentos. A qualidade do app é diretamente proporcional à sua senioridade!

Quanto mais júnior você for, pior vai ser seu app, com ou sem IA. Quanto mais sênior você for, melhor vai ser seu app, com ou sem IA. A IA é correlacionada diretamente com seu conhecimento E sua experiência.

IAs não são gênios com vontade própria. Elas não vão adivinhar o que você QUER e nem o que você REALMENTE PRECISA.

O que você QUER e o que você PRECISA costumam ser BEM diferentes.

Não adianta colocar segurança da NASA num sistema que não precisa. Não adianta deixar senha de admin aberta e colocar em produção. Você precisa saber quais são os limites certos pro seu caso de uso particular.

IAs são máquinas de probabilidade, cuspidores de texto glorificados, sem nenhuma inteligência. Elas nunca vão alcançar 100% porque isso é impossível.

E eu digo “matematicamente” impossível. Isso porque a quantidade de esforço/recursos necessários pra subir cada por cento nessa escala, aumenta exponencialmente. Como se diria em Cálculo “no limite”, o 100% vai pra infinito.

Então sempre necessariamente vai ser “abaixo de 100%”.

Os 99% do esforço servem pra fazer um app to-do list mínimo. O resto do caminho: escalabilidade, otimização, segurança, mantenabilidade, etc dependem unicamente de quem está pedindo: você.

Russian Doll de LLMs

Essa brincadeira de Opus ➡️ GPT 5.2 ➡️ Kimi 2.5 ➡️ Gemini 3 Pro ➡️ MiniMax V2.1 foi até barato, no total só uns USD 3. Mas novamente, é um app menor que um to-do list. “Deveria” ter sido trivial pra qualquer um deles, não acham?

Vamos rapidamente dar uma olhada no que as LLMs fizeram depois que meu appzinho já estava pronto.

Pra quem não viu o artigo anterior, o código final está neste GitHub.

1. Opus 4.5

Já tinha dito isso antes e repito, na dúvida, use Claude Code. É o melhor balanceado entre velocidade e qualidade. Se usar o plano Max, também é um bom custo-benefício. Concordo que ele é superior ao GLM 4.7, isso nunca foi uma questão.

Ao mesmo tempo, não é mágica e nem é infalível, muito longe disso. O processo todo que descrevi no artigo anterior vai ser exatamente o mesmo, só vai demorar bem menos (custando menos da minha paciência).

O GLM realmente apanhou muito na checagem de CORS e como o Opus demonstra, ainda sobraram bugs nessa checagem.

O Opus ajustou algumas coisas que são ok, mas desnecessárias. Melhorar a criptografia da comunicação não era necessária, porque era só uma obfuscação. A encriptação de verdade sempre vai ser TLS. Mas tudo bem, é bom manter ajustado.

Mas o que o GLM deixou passar reto e o Opus também é que na primeira versão o token era encriptado porque ia na URL, mas depois que mudamos pra server-side, não precisava mais. Mas ainda “sobrou” código velho disso, e o Opus, em vez de remover, tentou melhorar esse código velho!!

Deveria ser óbvio que não precisa: é server-side, o novo token é só um ID aleatório. Não tem nenhuma necessidade de manter um timestamp encriptado no servidor.

Ele também quis consertar a possibilidade de overflow na hora de carregar arquivo de I18n. Mas isso é algo que eu controlo, não o usuário. Não tem como ter overflow. É overengineering, mas tudo bem também.

Opus tende a ser proativo demais em aspectos que costumam ser desnecessários, dando impressão que é mais inteligente do que realmente é.

Sabe aquele estagiário chato que lê muito blog post e em toda reunião fica soltando coisas aleatórias pra mostrar que sabe? Mas que na prática não faz nenhuma diferença? Pois é, é isso.

2. GPT 5.2 Codex

Apesar de ser OpenLieAI, eu acho o GPT 5.2 Codex mais “honesto” do que o Opus. Ele não tenta ser tão smartpants o tempo todo, querendo se mostrar onde não precisa. Eu acho que ele vai mais direto ao ponto e segue mais de perto exatamente o que eu pedi, em vez de tentar fazer tangentes que eu não pedi - e acabam sendo desnecessárias.

Só desta vez, sei lá porque, ele fez o pior commit message de todos (super curto e sem explicação). Mas ele achou uma coisa bem idiota que GLM e Opus não prestaram atenção: configuraçãozinha boba de timeout:

Pro meu app, não é necessário. Mas neste estágio que eu realmente pedi pra analisar EXTENSIVAMENTE, me surpreende que o prolixo do Opus deixou passar isso.

E o GPT esbarrou no problema que falei acima do token encriptado: tive que interromper quando ele começou a tentar reimplementar a encriptação porque viu sobras do passado. Nesse caso eu mandei explicitamente remover essas sobras. Mas nem GLM, nem Opus e nem GPT se ligaram que isso não era mais necessário e continuaram tentando mexer nessa sobra velha.

3. Kimi 2.5

Toda semana surge mais uma versão nova que todo mundo fica hypando. 3 semanas atrás era MiniMax v2.1, 2 semanas atrás era GLM 4.7, agora é Kimi 2.5, então resolvi testar ele pelo OpenRouter. E o TL;DR é que eu gostei dele.

Achei mais lento que Opus ou GPT, mas melhor que GLM. E ele realmente continuou achando itens que não sei como o Opus deixou passar.

Novamente, é uma coisa besta e desnecessária pro meu appzinho, mas ninguém até agora se preocupou em configurar headers de segurança:

Em um web app de verdade, tem que colocar!

Outra coisa desnecessária mas que precisa num app de verdade: pattern de WebSocket Ping/Pong pra não desconectar se ficar idle:

O interessante foi o Opus não ter sugerido isso. Viram? Ele é prolixo, fica sugerindo um monte de pequenas coisinhas desnecessárias pra parecer inteligente, mas as coisas realmente interessantes, ele não lembra.

Mas aí o Kimi também sugeriu colocar de volta uma funcionalidade que eu tinha mandado o GLM tirar: rotina de limpeza do storage de tokens in-memory:

Como já expliquei: isso é server-side. Quando acabar espaço, automaticamente o novo token toma lugar do mais antigo e pronto. Mas o Kimi provavelmente ficou preocupado de deixar tokens expirados sobrando na memória. Só que é overengineering: é um storage hiper pequeno, kilobytes, talvez. Não precisa deixar uma rotina rodando em background pra ficar limpando uma lista em memória.

Mesmo num app de produção, eu não colocaria isso!

Teve um tweet de brincadeira sugerindo que o Kimi era uma versão pirata do Claude. Apesar de ser piada, esse comportamento de ficar implementando coisas desnecessárias que nem um estagiário que lê blog post e quer ficar se mostrando, é realmente bem parecido com o Claude. 😂

4. Gemini 3 Pro Preview

Diferente do Opus, assim como GPT, eu tendo a pensar no Gemini como sendo um pouco mais “honesto” e direto ao ponto também. Às vezes eu ainda pego ele se enrolando e sugerindo tangentes desnecessárias, mas no geral eu sinto que ele se prende ao meu prompt um pouco mais de perto mesmo.

No caso dele, além da análise, eu pedi explicitamente pra reavaliar a necessidade da rotina de cleanup que o Kimi adicionou a mais.

E o Gemini concordou com o Kimi e quis manter, e ainda otimizou a rotina!! 🤦‍♂️

Mas pelo menos ele ainda achou um deadlock durante o shutdown do servidor que ninguém antes pensou. Não é nada grave, e é só na situação de shutdown, mas mesmo assim, eu pedi uma análise EXTENSIVA de todos os anteriores, eles sugeriram coisas desnecessárias, e pularam isso. Num app de produção é importante ter esse cuidado. É o tipo de coisa que pode bloquear restart de containers em produção ou causar delays/timeout sem sentido.

5. MiniMax v2.1

A esta altura eu realmente espero que não tenha mais muita coisa que precise mexer, mas o MiniMax ainda achou mais coisinhas bestas faltando.

O Kimi colocou headers de segurança faltando no servidor HTTP mas esqueceu de fazer o mesmo pra WebSockets:

E a esta altura, 5 LLMs depois, ainda tem algumas besteiras de boas práticas de Go que todo mundo deixou passar. Esta bobagem, por exemplo:

De novo: isso não é nada. Mas todo mundo checou, analisou, rodou linters e tudo mais e só o MiniMax consertou essa sobra. SEMPRE TEM SOBRA

Conclusão

Dá pra continuar, eu poderia continuar rodando mais LLMs em cima disso. Mas lembrem-se: isso tudo foi só em cima de um appzinho miseravelmente pequeno, menor que um to-do list. Imagine num app grande, complexo, com usuários de verdade, em produção?

Não subestimem programação, é muito mais complexo do que vocês, iniciantes, pensam.

Eu acabei de rodar o equivalente a dezenas de bilhões de dólares, devo ter queimado energia suficiente pra abastecer uma casa inteira nos datacenters da Z.AI, Anthropic, OpenAI, Google, etc e ainda assim, tem sobras.

E mesmo com tudo isso, eu não tenho confiança nenhuma de colocar este appzinho em público. Pro meu uso pessoal privado está overengineered, mas pra produção, eu ainda precisaria gastar horas de revisão manual e testes manuais, QA extensivo, scans de segurança e tudo mais pra garantir que não sobrou nada importante ainda.

LLMs são EXCELENTES, me ajudam muito. Mas são estagiários muito motivados, e não gênios que fazem tudo sozinhos. Longe disso.

Isso é um conceito que falei múltiplas vezes nos vídeos do meu canal e em palestras. Tudo em programação acontece mais ou menos na proporção de Pareto: 80/20:

• 80% do código é “fácil” e normalmente feito em 20% do tempo. Os 20% mais importantes vão ocupar a maioria dos 80% do tempo total.
• Bugs e problemas como performance ou segurança, se consertar os top 20%, vai resolver 80% dos problemas gerais.
• 20% do escopo é realmente importante, por isso sempre dá pra simplificar, substituir, mudar, ou até cortar 80% - e é assim que se ajusta um projeto pra caber em orçamento/prazo.

Tudo é baseado em Top X. Aprender a priorizar é aprender a identificar os 20%. A diferença de alguém sênior/experiente vs alguém amador/iniciante, é que iniciantes acham que 100% é importante e não conseguem decidir os 20%. O que a experiência traz é a capacidade de cada vez separar mais rápido esses 20%.

PORÉM, é muito fácil só dizer isso. Todo mundo já ouviu isso pelo menos uma vez na vida, mas provavelmente ainda não consegue entender o que significa. Por isso resolvi fazer este (LONGO) artigo: vou mostrar na prática o que são os 80% fáceis e os 20% difíceis e como isso realmente afeta a qualidade do código, o tempo gasto e o custo.

Este artigo é para iniciantes, principalmente, mas também pra você: sênior que tem júniors pra mentorar ou professores com alunos. Usem como material de discussão e estudo com seus aprendizes. Esse é o tipo de coisa que se deve ensinar.

Como vai ser longo, lembrem-se que na versão desktop, do lado direito 👉 tem um menu com as seções pra pular direto pra cada assunto e estudar aos poucos.

O App: TV Clipboard

Escolhi um appzinho que eu queria faz tempo pro meu uso pessoal. É mais simples que um to-do list, não precisa de banco de dados nem nenhum outro serviço externo. Na prática é um comunicador peer-to-peer (p2p) via websockets.

O caso de uso é o seguinte: eu tenho um mini-PC gamer que conecto na TV da sala. Normalmente deixo um mouse do lado da poltrona pra navegar nele (é um maldito Windows 11). Mas eventualmente eu preciso digitar alguma coisa (senhas, preencher algum formulário). E eu não quero deixar minhas contas importantes logadas nesse PC (não confio em PC gamer).

Ou eu tenho que pegar meu teclado bluetooth, ou usar o teclado virtual do Windows. Ambas as opções são inconvenientes pra uma sala. MAS, e se eu pudesse abrir um site (que já vai estar no bookmark), aparece um QR Code que eu abro via meu smartphone e dali posso digitar ou colar o que está no meu clipboard mobile e transferir pro clipboard do mini-PC imediatamente? Esse é o app:

Daí eu abro a câmera do meu celular, escaneio esse QR Code e ele vai abrir esta página:

Pronto, agora posso digitar qualquer coisa ou colar a senha do meu gerenciador de senhas (clicando em “paste”) e quando enviar, na TV vou ver o seguinte:

Vai aparecer que recebi, e automaticamente já vai pro clipboard da TV. Ele mostra “blurred” porque se for uma senha não quero que fique legível grande na TV - e sim, o mouse é gigante porque é mais fácil de eu ver na TV.

Isso é útil não só pra TV, mas pra qualquer situação onde eu queira mandar textos do meu celular pra um dos meus PCs também. Muita gente acaba usando WhatsApp ou outros comunicadores pra isso. Eu, por exemplo, tenho um grupo “Só eu” que só tem eu nele, pra ficar mandando links e coisas bobas do meu celular. Daí eu sempre deixo o WhatsApp Web aberto numa aba do meu PC e posso pegar de lá. WhatsApp pra mim é um clipboard remoto.

Mas isso não é seguro pra mandar coisas como senhas, endereços de cripto, ou qualquer outra mensagem mais sensível. WhatsApp é uma empresa sem nenhuma transparência. A propaganda “diz” que eles têm encriptação de ponta a ponta, mas eu não acredito nisso. É igualmente provável que eles abram tudo no meio do caminho e deixem registrado - são dados que valem dinheiro, ainda mais nesta era de treinamento de LLMs.

Recomendação: NUNCA COMUNIQUE NADA IMPORTANTE VIA WHATSAPP.

Pra transferir arquivos eu já uso LocalSend:

Daí que veio a inspiração: eu queria um LocalSend pra Clipboard. Eu tenho certeza que já existam dezenas de apps que fazem exatamente isso. Mas aí eu queria aproveitar pra fazer este exercício.

O Plano: 100% Vibe Code

Honestamente, eu sei o suficiente de front-end, comecei minha carreira sendo “web master” nos anos 90. Mas eu detesto front-end. É demorado, é trabalhoso, yuck. Em particular, detesto lidar com CSS. Em mais particular, não tenho prazer em fazer Javascript. Por isso, sempre tenho preguiça de começar um web app do zero. Mas com Vibe Coding, essa é uma das partes que eu já posso me livrar, especialmente se eu não me importo com a aparência exata que vai ficar, contanto que não fique torto.

Aproveitando, vou usar uma linguagem que eu sei o básico mas não tenho nem experiência suficiente e muito menos fluência (ou seja, sozinho eu seria lento): GoLang. Por que Go:

• compila binário nativo: eu nem preciso da performance mas ter um compilador vai ajudar a LLM ter feedback de erros óbvios.
• sem dependências: depois vou querer fazer deploy no meu home server, e vai ser infinitamente mais fácil fazer o setup de docker com um binário sem dependências, comparado com um Ruby ou Python que tem que instalar muita coisa.
• ferramental padrão completo: além de compilador ele já tem formatador, linter, testes e tudo mais que também vai dar bom feedback à LLM
• sintaxe simples, curta e pouco ambígua. Gosto como Go é Python-like. Não considero nenhuma das duas “bonitas” (em termos de estética, eu prefiro muito mais um Swift, Kotlin ou Ruby). Mas diferente de Javascript e até mesmo Rust, é bem menos “verbose” e bem menos ambígua.
• standard library rica. Diferente de Javascript, não precisa ficar instalando 500 libs externas pra coisas básicas.
• como vou usar websockets, channels de GoLang vão facilitar minha vida. O mecanismo assíncrono dele é mais simples, robusto e melhor do que reactor de Node.
• o mais importante: porque eu quero. É um projeto pessoal, que só eu vou usar, eu escolho o que bem entender e ponto final.

Aliás, como eu não sou fluente em Go, provavelmente vou deixar passar alguma má prática ou anti-pattern óbvio. Se isso acontecer, você que é sênior de Go, não deixe de comentar abaixo explicando o que acha.

Se quiserem já ver como ficou, o código todo está neste GitHub. Eu vou ficar linkando trechos dele o tempo todo.

Outro objetivo é testar o quão bom o famoso GLM 4.7 realmente é. Já escrevi posts e tweets sobre ele antes. Já tentei rodar a versão Flash no meu PC local (é bom, mas BEM lento). No geral, minha impressão é que ele tem qualidade similar a um Claude Opus, GPT Codex, Gemini, mas é BEM mais lento (no mínimo 2x mais lento). Significa que se eu tivesse usado Gemini ou Claude, chegaria no mesmo resultado, mas talvez levasse metade do tempo, porém com um custo maior de tokens (GLM é mais “barato”).

Vamos ao TL;DR: ele conseguiu implementar o app como eu queria, mas DEMOROU. Eu levei um dia inteiro, almoçando e jantando na frente do PC enquanto o Crush ficava pensando, um total de mais de 10 HORAS. E, segundo o OpenRouter, gastei pouco mais de USD 40 (mais de 200 reais). Não foi nem rápido nem barato, considerando o escopo do app. Lembrando: é mais simples que um To-Do List.

Em termos de tamanho, mesmo um app simples destes deu mais de 3.000 linhas de código (LOC) de GoLang:

=== Code Statistics ===

Total Go code: 3493 lines

Production code: 1431 lines
Test code: 2062 lines
Test ratio: 1.44:1

Top 10 largest files:
  3493  total
  602  ./pkg/server/server_test.go
  560  ./pkg/hub/hub_test.go
  385  ./pkg/token/token_test.go
  304  ./pkg/hub/hub.go
  283  ./pkg/server/server.go
  263  ./i18n/i18n.go
  262  ./pkg/config/config_test.go
  253  ./pkg/QR Code/QR Code_test.go
  243  ./pkg/config/config.go

E de Javascript deu mais de 1.000 LOC:

=== JavaScript Code Statistics ===

Total JavaScript code: 1360 lines

Production code: 787 lines
Test code: 573 lines
Test ratio: 0.73:1

All JavaScript files:
  1360  total
  573  static/js/test.js
  313  static/js/client.js
  249  static/js/host.js
  114  static/js/common.js
  111  static/js/i18n.js

Ah sim, de curiosidade, adicionei scripts loc.sh e loc-js.sh pra fazer essa contagem.

Fase 1: Fazendo “Funcionar” - o que isso significa?

Diferente do que muitos amadores podem pensar, não basta digitar a descrição da aplicação (como eu fiz na seção anterior), como um prompt, jogar na LLM e ele vai automaticamente sair com um app que funciona: NÃO VAI.

É o que eu falava 2 anos atrás e continua sendo assim: não importa quanto mais as LLMs evoluírem. Eles podem ficar um pouco mais rápido, um pouco mais eficientes, mas a arquitetura ainda é a mesma desde 2022: transformers são geradores de texto glorificados, com um fator de sorteio aleatório que sempre vai embutir entropia no processo (nunca vai ser exato, determinístico). SEMPRE vai precisar de intervenção humana (e bastante).

Agora vou demonstrar com um exemplo real o que isso significa.

No final, eu parei este projeto depois de 43 commits. Eu segui o processo que sempre digo que é o melhor: fazer prompts pequenos, uma funcionalidade de cada vez, checar que funciona e está correto, mandar fazer git commit e partir pra próxima funcionalidade ou requerimento.

Numa conta de padeiro, cada commit ficou pronto depois de uma meia dúzia de prompts, em média. Vamos dizer que foi então 43 commits x 6 prompts = quase 258 prompts ao longo de mais de 12 horas. Alguns prompts foram uma frase simples que resolveu em 2 segundos. A maioria levava minutos e múltiplas iterações do agente (Crush).

A janela de contexto do GLM 4.7 é média: uns 200 mil tokens. O Crush tem um mecanismo que quando chegar muito mais de 90% de uso, ele manda resumir o contexto até agora, pra poder resetar e recarregar desse resumo pra continuar. Mas ele ainda tem bugs e às vezes crasheia e perde o contexto:

Aí eu preciso recuperar o último prompt, às vezes eu mesmo digitar parte do contexto que foi interrompido, pra ele conseguir continuar de onde parou. É trabalhoso e precisa ficar prestando atenção. Esse é um problema que um Gemini tem menos porque a janela de contexto dele é MUITO maior (mas a atenção no meio vai degradando, quanto maior vai ficando, é um trade-off).

“Ah, o Akita só pode ser burro. Eu já fiz um app de Todo e não chegou nem perto de 250 prompts. Ele fez errado.”

Agora vamos começar a parte que separamos os meninos dos homens. De fato, pra “fazer funcionar” não precisa de tudo isso de prompts. Dos 43 commits que levaram 10+ horas, eu já tinha um app que “funcionava” depois de 10 commits pequenos, que levou cerca de 1 hora.

Se quiserem ver a versão “v0.1”, basta fazer assim:

git clone https://github.com/akitaonrails/tvclipboard.git
cd tvclipboard
git fetch --tags
git checkout v0.1

Esta versão tem 1.827 LOC de GO e 255 LOC de Javascript. Mas o backend Go mesmo tem só 549 LOC vs 1.431 LOC no final. E isso porque nesta versão mínima eu já adicionei testes unitários de backend (1.278 LOC), que a maioria dos iniciantes nunca coloca. Então daria pra “resolver” meu problema em pouco mais de 800 LOC, menos de 1 hora e meia dúzia de prompts.

A estrutura do projeto ficou assim. Guardem esta imagem pra comparar como vai ficar no final:

Nesta versão já abre o que eu chamo de página “host” que é a página que abriria na minha TV, mostrando o QR Code pra conectar. Já tem a página “client”, que é o que o QR Code vai abrir no meu celular. E já consegue colar texto no cliente, mandar pro host e copiar no clipboard dele. Bem simples.

É aqui que 99% das pessoas iriam parar e dar por completo.

Fase 2: Indo além de “só funcionar”

Vou repetir: este projeto é mais simples que um todo list e é feito exclusivamente pra somente eu usar, em casa, na minha rede local. Qualquer um que pensar “ah, isso tudo é desnecessário pra esse app” - EU SEI!.

A ideia é demonstrar o mínimo que se precisa pensar num projeto de verdade. Se estiver fazendo um brinquedo só pra você sozinho, tanto faz a qualidade.

Pra quem for sênior de Go, ou Javascript (porque vou usar no front), eu sei que vocês vão pensar “ah, ele deveria ter usado framework X ou biblioteca Y” - EU SEI!! 😅 No final vai ter uma seção onde vou discutir um pouco dessas outras opções, esperem antes de sair comentando!!

Voltando ao conceito de Pareto. Eu falei que 20% do trabalho mais importante custa 80% do tempo, mas isso é só uma ordem de grandeza. No meu exemplo, o projeto todo levou mais de 10 horas e “pra funcionar” levou só 1 hora. Então está mais pra 90/10 em vez de 80/20.

O que diabos custou 90% do tempo se em 10% “já funcionava”??

1. Gerenciamento de Tokens

A primeira coisa que eu penso quando vejo um QR Code é que o link dentro dela seja descartável e volátil. Não é uma regra e obviamente depende do app. Pro meu appzinho é sim “overkill” mas vou fazer pra dar de exemplo. (não vou ficar repetindo toda hora “sim, pro meu app não precisava”, esta é a última vez).

Eu não quero que uma visita que use meu app em casa consiga bookmarkar o link e conseguir usar fora daqui (eu vou expor meu serviço na internet pra conseguir usar de qualquer lugar depois). Eu quero que cada uso seja único e que expire depois de alguns minutos, exigindo um novo QR Code.

Portanto eu preciso de algum sistema de tokens que expira.

Este artigo já vai ser muito longo, então não vou ficar copiando o código inteiro de cada funcionalidade. Vou sempre indicar o commit onde implementei pra vocês pesquisarem depois e mostrar só trechos pra ilustrar.

Enfim, o objetivo vai ser ter uma URL como http://clip.example.com/?token=blablabla. Nada de outro mundo.

Sim, poderia ser um JWT, mas meu uso é muito simples então mandei fazer do zero e o GLM 4.7 inventou uma estrutura JSON com uma chave privada aleatória e um timestamp, que ele resolveu encriptar com AES (não precisava mesmo) e encodar em hexadecimal pra ser o token (fica hiper longo, mais de 100 caracteres).

Ficou um monstrinho assim:

Eu não gostei mas resolvi deixar assim porque está funcionando. Eu posso mexer nisso mais tarde - inclusive, muita coisa foi feita “fora de ordem” porque eu fui fazendo à medida que ia lembrando. Não tinha um planejamento passo-a-passo escrito antes. Literalmente tirei da cabeça em tempo real mesmo.

O objetivo disso é lembrar que Gerenciamento de Sessão é uma preocupação que todo dev tem que ter na cabeça num sistema de verdade.

2. Primeiro Refatoramento

O código principal já estava com mais de 500 LOC, os testes com mais de 1000 LOC. Isso é muito grande pra ficar num arquivo só. Então pedi pro GLM refatorar em pacotes. Esse tipo de coisa eu sei que o Claude Code faz com mais facilidade, mas o GLM se saiu bem também. No final ficou algo assim:

Isso é o que chamamos de “Separation of Concerns”. Cada pacote tem um domínio isolado. Um pacote pra lidar só com opções de configuração, outro pra cuidar só do servidor HTTP, outro pra lidar só com a geração de QR Code e outro pra lidar só com gerenciamento de Tokens. Cada um com testes unitários no mesmo pacote.

Pedir pra fazer testes desde o começo foi uma grande ajuda à LLM, porque vira e mexe ele rodava o teste, ficava confuso do porquê não funcionava e caia a ficha que precisava ajustar a implementação. Todo feedback automatizado é importante pra LLM ter contexto pra trabalhar.

E refatoramento não é algo que se faça apenas uma vez. É um processo que tem que ser feito de tempos em tempos pra consolidar e simplificar o código, melhorando a mantenabilidade.

O objetivo disso é lembrar que “só porque funciona”, não significa que o código fica congelado e não se mexe mais.

3. Suporte a Docker

Como eu iria rodar no meu home server, suporte a Docker é obrigatório. Mas independente disso, é uma boa prática manter um Dockerfile que funciona. É outro tipo de “teste automatizado”: ver se consegue “buildar” uma imagem e rodar. E documentar pra outro usuário que ele não precisa instalar nada no sistema dele pra rodar, basta rodar o Docker:

docker run -d \
  --name tvclipboard \
  -p 3333:3333 \
  akitaonrails/tvclipboard:latest

Inclusive, o comando acima funciona, caso você queira testar imediatamente. Eu subi a imagem na minha conta no Docker Hub.

E se já não tinha implementado assim, isso também força que você adicione opções de configuração na forma de variáveis de ambiente (como TVCLIPBOARD_SESSION_TIMEOUT) ou via argumentos em linha de comando (como --expires), expondo o que é configurável.

O objetivo aqui é lembrar como é importante automatizar build e documentar como usar pra outras pessoas.

4. Organizar Javascript e adicionando Cache Busting

Pra “só funcionar”, lá no começo, bastava fazer um “index.html” e ir escrevendo if host ou if client no meio do HTML e JS. Mas pelo menos o GLM iniciou duplicando um host.html e um client.html. Mas o javascript estava todo inline entre tags <script>...</script> e duplicado nos dois arquivos, então outro passo de refatoração foi pedir pra ele separar common.js, client.js, host.js.

É o mínimo do mínimo de mantenabilidade. Novamente: refatoração não acaba num passo só.

Mas eu poderia esbarrar num problema. Sendo um sisteminha muito simples, não tenho nada de ETAGs implementado e nem asset pipeline como WebPack ou similares.

Num web framework dinâmico, a maioria vai ter suporte a gerar arquivos de CSS e JS dinamicamente mudando os nomes pra coisas como /assets/host-20260128123456.js e toda vez que editarmos algum JS, o pipeline vai regenerar esse arquivo com outro nome.

Quando abrimos num navegador web, ele vai sempre tentar “cachear” assets estáticos como imagens, JS, CSS, pra não ficar pedindo a mesma coisa toda hora. Se ele já baixou host.js, no próximo “reload”, se pedir o mesmo arquivo, basta pegar do cache em vez de pedir pro servidor de novo.

O problema disso é se mudarmos o conteúdo do arquivo e manter o mesmo nome. O navegador vai achar que é a mesma coisa e você vai ficar horas coçando a cabeça pensando “porra, eu já consertei isso, porque não aparece??” - e pode ser cache.

Pra evitar isso, existem técnicas de Cache Busting, como cabeçalhos ETAG. Mas o mais comum é só adicionar algum tipo de indicador de timestamp na URL, por exemplo /static/js/host.js?v=20260128120431. Desta forma, sempre que meu servidor reiniciar, o timestamp vai mudar (não é a melhor regra, mas pra agora funciona). A URL vai ser diferente e o navegador vai ser forçado a baixar a versão mais nova, garantindo que eu não perca tempo caçando problemas de cache.

Novamente, qualquer web framework minimamente competente, com suporte a templates de HTML, vai ter isso, mas eu pedi pra fazer do zero:

Como eu sirvo páginas estáticas de HTML, o código do meu servidor precisa modificar as URLs antes de mandar pro navegador, e é isso que o commit acima faz.

Ao escrever este post, notei que ele adicionou cache busting pros arquivos “.js” mas esqueceu do “style.css”, que ficou sem. Eu não notei porque não mexi quase nada no CSS original que ele fez. Mas novamente, pra demonstrar que LLMs nunca são perfeitas e tem que ficar constantemente checando se ele não esqueceu nada ou deixou sobrar coisas. Mandei ele consertar neste último commit

O objetivo aqui é lembrar que não basta só jogar arquivos no servidor sem saber como eles são servidos. Todo front-end precisa saber como um navegador funciona. Não basta “saber HTML”.

5. Adicionando Argumentos de Linha de Comando e fazendo mais limpeza

Os próximos três commits são besteiras que eu deveria ter feito squash num único commit.

Aqui é mais pra lembrar que não é inteiramente ruim deixar um agente como Crush fazer git commits automaticamente, mas precisa prestar atenção pra talvez ter que mandar desfazer (git tem como refazer commits, com opções como -amend).

Eu só adicionei opções de linha de comando. Agora o binário tem este suporte:

E como ele esqueceu de documentar no README, o outro commit é pra isso. Por isso falei que o certo era dar squash num commit só, porque são a mesma tarefa.

6. Configuração de ambiente de Dev vs Produção

Este é outro ponto que todo iniciante ignora. O famoso “ah, mas na minha máquina funciona”.

Em web, principalmente, a “sua máquina”, sempre vai ser um localhost, ou 127.0.0.1 ou 0.0.0.0 (assista à minha playlist sobre Redes) pra entender a diferença.

O problema: se subir esta app localmente no meu PC, eu acesso por http://localhost:3333. Quando o QR Code for gerado, ele vai usar “localhost”. Agora imagine seu celular tentando carregar um link de “localhost”. Obviamente, não vai funcionar. Porque no seu celular não tem o aplicativo rodando nessa porta em localhost. Eu preciso do IP do meu PC. Então, a primeira coisa que preciso pedir pra corrigir é que, caso seja localhost, que ele procure o IP do meu PC - que vai ser algo como 192.168.0.xxx. Estando meu PC e meu celular no mesmo DHCP, na mesma rede, eles conseguem se achar por esse IP privado.

Mas e quando eu subir num Docker? O IP interno de um Docker é diferente do IP externo (o container sempre está ou em NAT ou em Bridge). O IP “externo” do container vai ser algo como 192.168.xxx, mas o IP interno vai ser algo como 172.xxx. Novamente, se o QR Code usar o IP interno, vai dar problema.

Então eu preciso de uma nova configuração, que normalmente se chama PUBLIC URL ou PUBLIC HOST ou só HOST. Onde eu declaro explicitamente.

Por exemplo, quando terminar, como falei, vou deixar meu serviço exposto na internet usando um domínio válido pessoal. Algo como https://clip.example.com com suporte a TLS e tudo mais. Então eu preciso que no docker-compose.yml eu consiga ter uma opção assim:

  - TVCLIPBOARD_PUBLIC_URL = https://clip.example.com

E assim o QR Code é gerado com este nome em vez de ter que tentar adivinhar. Mas ao mesmo tempo, se não passar nada, assume “localhost”.

Neste primeiro commit ele ainda não faz tudo isso - eu fui fazendo aos poucos. Mas é como se começa esse tipo de funcionalidade.

O objetivo aqui é lembrar que “rodar na minha máquina” (localhost) não significa nada. Não vamos colocar “sua máquina” em produção. “Funcionar” significa “funcionar FORA da sua máquina”.

7. Mais limpeza de código

Estou de propósito mencionando “limpeza de código” o tempo todo pra que fique bem claro que uma parte considerável do trabalho de programação é “limpar” código que já foi feito.

Os próximos quatro commits são só manutenção.

Por exemplo, sem querer a LLM largou um trecho duplicado dentro do código. Não quebrou nada porque foi na configuração de Docker Compose:

Além disso, tem um comportamento acidental na forma como este app funciona que resolvi deixar como “feature”. Sempre precisa ter um navegador que abre primeiro que automaticamente se torna o Host e exibe um QR Code. O próximo navegador a abrir precisa do link desse QR Code e vira o “client”.

Mas quando o host fecha, o client perde a conexão e automaticamente é promovido a host. Eu não pedi pra ser assim mas acabou ficando, então pedi pra deixar e documentar.

O objetivo aqui é lembrar que LLMs não são perfeitas, vão deixar sobras pra trás, e você precisa ficar o tempo todo monitorando.

8. Otimizando Javascript

Os próximos três commits são pra dar uma limpeza no Javascript.

Da última vez que mexemos, eu só tinha pedido pra ele tirar os Javascript inline do HTML e separar em arquivos “.js” reusáveis. Mas chegou a hora de dar uma olhada neles.

De cara, deu pra ver que tinha duplicação entre client e host, então pedi pra deduplicar e jogar no “common.js”.

Além disso tinha vários pequenos probleminhas:

• um monte de variáveis e funções no escopo global (poluição de global: má prática)
• websockets que abrem mas sem nada checando o fechamento
• timers sendo ativados mas nunca desativados (leaks)

O código Javascript “que funciona” sempre é assim: tudo global, tudo aberto, nada checado, vários leaks. Isso é normal e toda LLM vai fazer assim.

Também não acho que precisa fazer prompts desde o começo exigindo SOLID e tudo mais. Primeiro faz funcionar, depois faz funcionar direito, finalmente faz funcionar rápido. É sempre nessa ordem, especialmente num escopo simples com este.

Por isso agora é hora de pedir pra refatorar. E a primeira coisa a fazer é sempre isolar o escopo, por exemplo, num bloco assim:

(function() {
  'use strict';
  ...
})();

O problema disso é que toda função que o HTML pedia, como “onclick”, vai falhar porque agora não tem mais nada no escopo global. Uma vez tudo escondido, agora tem que ir expondo somente o que realmente precisa público.

Isso se chama IIFE Encapsulation (Immediately Invoked Function Expression). Tem milhares de práticas como essa que Javascript precisa pra ficar “mais limpo”. Eu sei, eu deveria estar usando módulos, Typescript, bla bla, mas esse é um exemplo simples mesmo.

O objetivo aqui é lembrar que, só porque “funciona”, não significa que “está bom”, principalmente com Javascript.

9. Otimizando o Golang

Esta é a seção mais longa. O código Golang já “funciona”, mas ele não está bom ainda. Eu sei que tem race conditions em channels, eu sei que o tratamento de erros está ruim, eu sei que ainda tem micro problemas de segurança, então quero consertar o que puder.

Os próximos 6 commits lidam com:

• Refactor: Improve error handling, race conditions, and graceful shutdown
• Fix: Critical race conditions, memory leaks, and security issues
• Security: Add message size validation and rate limiting to prevent abuse
• Config: Tighten security limits and add origin validation
• Fix: CORS origins, Web Crypto API fallback, and clipboard issues
• Fix: QR code uses correct port from PublicURL and document Web Crypto API HTTPS requirement

6 commits

O próprio GoLang tem ferramenta pra checar race conditions, o Data Race Detector. Basta colocar a opção --race em comandos como go build ou go test. E felizmente o GLM foi esperto e imediatamente usou essa ferramenta quando pedi pra checar esses problemas.

Race conditions acontecem quando duas tarefas assíncronas tentam modificar a mesma estrutura de dados, por exemplo. Uma das formas de “consertar” é colocando Locks ou Mutexes em estruturas que só podem ser modificadas sincronamente. Qualquer aplicação que tenha qualquer coisa assíncrona, eventualmente vai ter problemas de condição de corrida. Não é “talvez”, é “quando”.

Um servidor precisa ser “bem comportado”, não pode simplesmente “crashear”, dar “panic”. Mas o primeiro código “que funciona” que o GLM fez tinha vários trechos assim:

Isso está errado. Além disso precisamos que o servidor aceite corretamente sinais de sistema como SIGINT, SIGTERM, etc. É quando damos “Ctrl-C”, por exemplo, ou o Docker manda desligar o container. Ele não vai simplesmente crashear o programa, primeiro ele vai pedir pro programa se desligar sozinho, dando chance dele fazer limpeza, como dar flush em arquivos, fechar portas e coisas assim.

Isso se chama Graceful Shutdown.

Não parei pra checar o quão certo o GLM estava mas segundo ele mesmo, alguns dos problemas que ele mesmo encontrou, no código que ele mesmo fez, incluem coisas assim:

Como podem ver, só porque “compila”, não quer dizer que está ok. Só porque “roda”, não quer dizer que está ok. Mesmo pedindo pra checar MÚLTIPLAS VEZES a LLM não acha todos os erros de uma só vez. Cada um desses commits levou horas pra conseguir resolver e eu tive que intervir múltiplas vezes, e ainda assim eu ainda não tenho certeza que ele pegou tudo (precisaria revisar com mais calma - mas eu queria publicar este artigo logo 😂).

10. Adicionando Sistemas de Segurança

Novamente, nada disso é necessário num sistema que somente eu vou usar na minha rede local, mas você como desenvolvedor precisa se responsabilizar.

SEMPRE considere que todo usuário do seu sistema é MALICIOSO! Essa é a REGRA, não a exceção.

Um exemplo bobo: o usuário pode colar e transmitir qualquer texto via websockets pro meu servidor. As 3 coisas mais óbvias que imediatamente passaram na minha cabeça foram:

a) Quando o host recebe o texto, ele renderiza no HTML na caixa de “Recebido”

E se o usuário mandar um <script>....</script>? Isso vai renderizar no HTML e o navegador vai EXECUTAR. É assim que funciona Code Injection. É assim que funciona XSS (Cross-Site Scripting). Isso era muito comum em antigos fóruns ou sistemas de comentários. Pra evitar isso se deve SANITIZAR tudo que vem do usuário.

Felizmente, o jeito que o GLM fez já é sanitizado porque ele escreve o conteúdo com textContent em vez de innerHTML, então o texto é escrito literalmente sem executar:

Por acaso ele fez certo de primeira, mas precisa checar porque ele poderia ter feito errado.

b) Não tinha checagem de tamanho da mensagem

Nunca um usuário pode conseguir enviar um texto de tamanho qualquer. Ele sempre pode tentar diretamente dar POST com um arquivo de gigabyte pra ver se estoura algum erro de Overflow no servidor, expondo algum exploit de segurança.

TODO campo de usuário precisa de limites e precisa checar não só no cliente/front-end, mas mais importante, no backend:

c) Tem que rejeitar Spammers!!

Novamente, não pode assumir que todo mundo vai usar seu web app bonitinho. A regra é achar que todo mundo vai tentar derrubar ou invadir. E uma forma de fazer isso é criar um script pra ficar fazendo milhares de POST por segundo pra tentar algum tipo de Denial of Service, onde o servidor enfileira tanta requisição que vai estourar.

O certo é configurar isso num outro serviço que vai ficar na frente do seu, como Cloudflare.

Mas não custa implementar um fallback na sua aplicação mesmo. Um jeito de configurar quantas requests um mesmo usuário pode fazer de cada vez (ex. 4 requisições por segundo - ninguém vai colar texto tantas vezes por segundo numa app dessas).

Se tentar mais que isso, o app tem que imediatamente REJEITAR e dropar a conexão, sem gastar tempo processando mais, liberando recursos pra outras requisições de verdade. Isso se chama RATE LIMITING.

d) Outro problema que iniciantes não param pra pensar é em CORS e Origin Check.

Como falei antes, temos Javascripts como /static/js/common.js. Não é nenhum grande problema outra pessoa usar porque não tem nenhum grande segredo neles. Mas no mínimo eu não quero que algum site “http://malware.pk/index.html” da vida inclua dentro dele um https://clip.example.com/static/js/common.js e eu fique pagando pelo tráfego dele.

Eu quero que somente a MESMA ORIGEM, no caso “clip.example.com”, seja capaz de carregar arquivos no mesmo servidor. Ninguém de fora é bem-vindo e isso é a BOA PRÁTICA. Estude CORS (Cross-Origin Resource Sharing). Isso é mais importante se seu sistema são múltiplos domínios onde um depende do outro, daí você quer - controladamente - permitir somente determinados outros domínios que estão sob seu controle.

Regra de tudo em rede é DENY ALL e depois ALLOW [específico]. NUNCA deve ser ALLOW ALL.

Pra implementar isso demorou um bocado, porque o GLM ficou se enrolando de como permitir “localhost”, mas também “192.168.xxx:3333”, mas também “clip.example.com” (via porta 443), etc. Não é difícil, só o GLM que se complicou todo e eu tive que intervir várias vezes com prompts pra colocar ele na direção certa. Acabou dando múltiplos commits até ele acertar.

e) Outro probleminha que iniciante não pensa: PERMISSÕES de recursos do navegador.

Toda vez que carregar esse sistema em “localhost” e ele receber a mensagem pra jogar no clipboard, vai aparecer este alerta pedindo permissão:

E isso é normal e correto: nada deveria ter acesso a coisas fora do navegador. Por isso o Javascript pede “manda pro clipboard”, daí o navegador intercepta, checa a permissão e, se não tem ele pede. Toda vez vai pedir. Mas se usar um domínio de verdade (ex. clip.example.com), ele vai perguntar uma vez e depois lembrar pra cada domínio. É um dos motivos pelos quais vou expor na internet: pra ter um domínio de verdade.

Expor serviços na internet é PERIGOSO. Por isso eu fiz este artigo explicando como usar domínios de verdade e este outro artigo sobre como usar Cloudflare Zero Trust.

f) Tinha outro fator de segurança que é “overkill” mas eu quis implementar mesmo assim.

Digamos que eu queira rodar somente em localhost. Digamos que seja uma rede privada, mas compartilhada (visitas, companheiro de quarto, escritório, etc). Ao rodar em localhost não vai ter TLS, ou seja, os pacotes HTTP vão trafegar em texto aberto.

Qualquer um com um Wireshark pode ficar “escutando” (“sniffing”) os pacotes na rede e interceptar os meus. E se justo eu estiver passando dados sensíveis, como uma senha, vai dar pra ver aberto.

O certo é rodar com TLS (HTTPS). Mas só pra um “quebra-galho”, pedi pro GLM implementar uma obfuscação simples (não é um processo totalmente seguro, mas usa AES-GCM), mas já serve pra não ficar óbvio com um sniffer. Pra isso ele vai usar Web Crypto API.

Mas tem um porém: Web Crypto API está disponível somente se o site abrir com HTTPS ou se for localhost. Mas se eu tentar http://192.168.xxx:3333, não vai estar disponível. Pra isso tem este commit pra lidar com isso e documentar.

O objetivo aqui é mostrar como aspectos de segurança, otimização, mantenabilidade são muito mais do que um iniciante pensa. Aliás, nunca vai pensar, porque precisa ter estudado antes pra saber que existe.

11. Licenças Open Source

Esse tema sozinho seria assunto pra um longo artigo, mas na prática eu tendo a pensar simples:

• se for um projeto que eu não me importo se alguém vai contribuir ou não, basta abrir com licenças PERMISSIVAS, como BSD, MIT
• se for um projeto que eu gostaria de ter contribuição e que ninguém use comercialmente, basta colocar uma licença RESTRITIVA, como GPL
• se for restritivo e for um app que poderia virar um SaaS (daí o código não é distribuído, então não precisaria contribuir), daí adiciona AGPL (Affero)

Foi o que eu fiz neste: coloquei licença AGPL 3.0.

O aviso é pra não deixar LLMs escreverem o arquivo de licença. Sempre pegue textos sobre leis, regulamentos e regras do site oficial. A LLM sempre produz uma versão resumida ou incompleta ou até errada mesmo. Documentos legais precisam ser EXATOS, não pode ter palavras erradas e sentidos ambíguos ou afirmações incompletas.

LLMs não são boas pra gerar textos legais corretos de primeira, sempre vai ter erros. Sempre assuma que textos assim estão errados: não existe “compilador” de leis.

12. Resolvendo o problema dos tokens longos demais

Lá atrás eu falei que os tokens que o GLM gerou pra mim são grandes demais (mais de 100 caracteres). Isso resulta em links super gigantes.

Não é um problema porque ninguém vai ter que digitar isso e nem é pra bookmarkar. Aqui é mais uma escolha pessoal mesmo: eu gosto de tokens curtos em URL.

A vantagem do token longo é que eu não preciso implementar nenhum tipo de “banco de dados” (key-value store, ou KV Store - Memcached, Redis). Isso porque toda a informação da sessão (ID e timestamp de expiração), estão encodados dentro desse token, por isso ele é longo. É uma struct json, encriptada com AES, convertida em Hex.

Tentando manter o mesmo conceito, neste primeiro commit eu pedi só pra ele tentar otimizar o tamanho da estrutura. Então o GLM sozinho escolheu tentar mudar de UUID (36 chars) pra um Hex ID aleatório de 24 chars. Trocar de timestamp padrão ISO (24 chars) pra UNIX (10 chars). Isso desceu dos 130 a 140 chars pra uns 112 chars. Uma redução na faixa de 20% a 25%.

Não foi uma tentativa ruim. Mas no final eu realmente não estava engolindo tokens grandes assim (poderia ser cookie também, eu sei, mas queria manter tudo na URL).

No final decidi que queria tokens realmente curtos (de 8 chars, base62) e aí precisaria guardar a Sessão em algum “storage”. Decidi que ia ser “in-memory” (afinidade ao processo, mas eu só vou rodar 1, sem load balancer, então tá ótimo). E isso seria um FIFO com rotação (chaves mais velhas vão sendo descartadas pra dar espaço pra chaves mais novas e pronto, elas expiram mesmo).

Este é o commit dessa funcionalidade e ainda tive que intervir várias vezes. Por alguma razão ele achou que seria uma boa idéia ter goroutine em background pra ficar limpando os tokens expirados desse storage. Mas isso é completamente desnecessário se for um FIFO. Ele fez, eu tive que mandar desfazer. Essa é a rotina.

13. Mais refatoramento e limpeza (quase acabando!)

Os últimos 6 commits são MAIS MANUTENÇÃO!!

Parece zoeira, mas isso que eu fiz de manutenção é até pouco. Num projeto de verdade isso faz parte da rotina. Toda vez que você adiciona alguma coisa nova, vai estragar alguma coisa que já tinha, e vai precisar ajustar pra não acumular débito técnico.

Lembram que rodamos checagem de race condition? Adicionamos código novo, tem que checar de novo. E ele achou mais problemas corrigidos neste commit. Não lembro agora se já tinha lá atrás e ele pulou sem corrigir, ou se nas últimas mexidas acabou gerando esses novos bugs.

Depois de tanto adicionar coisas e refatorar, resolvi aumentar mais um pouco a cobertura de código do Go. O comando go test tem a opção -coverprofile pra ajudar a checar quais partes do seu código não foram testadas ainda. Então pedi pro GLM adicionar testes pras novas funcionalidades como Rate Limiting, checagem de tamanho da mensagem, check origin e outras coisas.

Mandei adicionar uma besteira que é um botão de “Fechar” no lado cliente, pra não ficar acumulando tabs no meu smartphone.

Depois que mandei trocar o sistema de tokens, não precisa mais encriptar a estrutura de timestamp. Mas ele deixou pra trás testes unitários sobre isso. Então mandei tirar. Novamente: LLMs vão deixar coisas incompletas pra trás. Muitas vezes ele não sabe se mantém um código pra não quebrar o teste, ou se é pra tirar o teste porque o código não é mais necessário.

Depois pedi pro Go rodar linter e suporte a golangci-lint pra últimas checagens. Um Linter é tipo uma checagem de formatação, sintaxe e boas práticas de codificação numa linguagem em particular. Mas a maior parte dos ajustes foi espaços sobrando, poucas indentações erradas e coisas desse tipo. Nada de mais.

Uma última coisa que foi negligência minha mesmo, é que estava esquecendo de adicionar testes de Javascript. Uma parte considerável do código é front-end pra lidar com WebSockets e tudo mais. Precisa adicionar, e isso foi neste commit.

Como fiz tudo de uma vez só, aí já pedi pra adicionar ESLint também, e priorizar testar tudo só unitariamente, com mocks e stubs pra ser tudo headless e sem precisar carregar Chromium. Só testar as funções publicamente expostas mesmo. Isso elevou a cobertura de testes de front-end de zero pra 73%, o que é uma ótima cobertura. Veja o commit pra ver como ficou.

14. Última coisa: I18n

Isso foi uma coisa que lembrei enquanto já estava escrevendo este artigo. Completamente desnecessário, mas eu queria ver se o GLM conseguiria fazer. E “conseguiu”. Eu não detalhei como eu queria e deixei ele pensar na solução. Eu teria feito o servidor em Go fazer a troca dos strings antes de enviar o HTML pro client.

Mas o GLM preferiu adicionar isso no lado do front-end e trocar as strings via Javascript. Não está errado, mas não é o melhor jeito.

Justamente tradução de linguagens é uma coisa que IAs foram feitas originalmente pra serem boas: Processamento de Linguagem Natural (NLP). Mandei extrair todos os textos em inglês e depois fazer uma versão em Português do Brasil, e posso dizer que ele fez direitinho:

Num web app de verdade é uma coisa que sempre precisamos ficar preocupados: de não deixar mensagens pra usuário “hardcoded” e sempre ficar extraindo e testando. O que me leva à última parte:

Não era Melhor usar Framework X ou Biblioteca Y?

Povo de Go talvez não goste que eu não tenha usado Gin, Fiber ou outro web framework. Mas realmente neste caso o app é simples demais. Não tem mais que 3 endpoints. A parte mais complicada seria o WebSockets, que não ficaria muito diferente usando um framework. Ou checagens maiores como de CORS, que também não seria muito menos LOC.

No lado do Javascript, talvez I18n valesse a pena eu ter importado algum pacote pronto, mas novamente, é muito simples. Não tinha nenhuma grande funcionalidade que tive que reinventar a roda.

Claro, isso porque este app é miseravelmente pequeno, como falei no começo. Um app maior de verdade, eu recomendaria mesmo usar um framework popular com bom suporte da comunidade, bem documentado e tudo mais. Mas coisas do tamanho de um ToDo List realmente não faz diferença a menos que o exercício fosse aprender a usar determinado framework.

Pensando nisso, tem que tomar cuidado porque nenhuma LLM vai escolher pra você. Se começar com prompts pequenos, uma funcionalidade de cada vez (que é o jeito certo), ele tende a escrever as coisas tudo do zero, sem importar nenhuma biblioteca.

Você tem que saber de antemão que biblioteca vai pedir pra cada coisa!

Novamente, um iniciante não saberia, então acabaria reinventando a roda dezenas de vezes em vez de usar bibliotecas populares.

Lembram que falei, lá no começo, pra guardar como era a estrutura do projeto na versão v0.1 que “já funcionava”? Eis como fica no final num projeto de verdade:

Conclusão

Ufa! Foi Longo! Parabéns se chegou até aqui!

Minha experiência neste projetinho foi de ter um estagiário super motivado que eu precisei ficar o dia inteiro olhando atrás do ombro e toda hora falando:

“Opa! Para tudo, tá errado!” “Opa! Desfaz e faz de novo mas deste outro jeito!” “Opa! Não, você já tinha feito isso errado antes e tá repetindo!”

Não estou brincando quando falei que foram mais de 250 prompts. E isso é uma estimativa por baixo, eu acho que escrevi MUITO mais que isso.

Tão logo terminei o processo de Vibe Coding, já fiz push no GitHub e comecei a escrever este artigo, então ainda faltam horas de REVISÃO do código todo, do começo ao fim, pra ver se não deixei passar nada. Não daria pra colocar em produção sem fazer isso! Se alguém ver coisas estranhas no código, fiquem à vontade pra mandar nos comentários.

Foi realmente como se eu estivesse mentorando um estagiário. Mas com um problema: diferente de um estagiário de verdade, a LLM já se esqueceu de tudo que eu ensinei pra ele.

Quando for fazer um novo projeto com o GLM, ele vai cometer praticamente TODOS os mesmos erros e equívocos. É como se eu estivesse mentorando um estagiário cego e com memória de peixe dourado.

É extremamente cansativo!!

No final levou umas 12 horas pra codificar tudo, e eu tenho a impressão que um desenvolvedor sênior de Go teria feito sozinho na metade do tempo. Um júnior teria levado esse tempo, ao longo de uns 2 ou 3 dias (parando pra pesquisar).

Eu já sabia disso, já repeti dezenas de vezes, mas a noção de:

“Não preciso mais contratar programador, a IA faz tudo sozinha.” - é uma GRANDE FALÁCIA.

E não vai melhorar muito mais do que isso. Já estamos no topo da curva em S que eu expliquei em todo podcast que participei e nos videos do meu canal. Custa ordens de grandeza mais energia pra treinar a próxima versão do que levou todas as versões anteriores, pra ter uma evolução incremental.

Enquanto a arquitetura for a mesma, não vai sair disso. Precisa de alguma NOVA DESCOBERTA (que não aconteceu até hoje, desde 2021 quando saiu Transformers).

Um Claude Code vai ser um pouco mais rápido que GLM. A próxima versão do GLM vai ser um pouco mais rápido. Talvez o tempo de 12 horas que eu levei, vire 6 horas (pra este app miserável). Mas o PROCESSO vai ser o mesmo: ele faz errado, eu mando consertar, e faz isso ad eternum.

Não vai existir fazer um único prompt e no final sair um app perfeito, seguro, otimizado, etc. SEMPRE vai sair com bugs na primeira vez. Por isso que alguém que não é programador não deve fazer software pra colocar em produção só com Vibe Coding: precisa passar por revisão de um programador experiente de verdade.

Isso não é opcional.

Post-Mortem

Esta seção foi escrita no dia seguinte à publicação do artigo original. Depois de terminado, pedi ao Claude Code pra fazer uma análise profunda da qualidade, focando em segurança e testes. E ele achou VÁRIOS erros. Lembram que falei que não dava pra colocar em produção sem revisar com calma antes?

Este é o commit com os consertos, dêem uma olhada.

Então ele “Já funcionava” na Fase 1, com um monte de problemas. Eu intervi e gastei 90% do tempo na Fase 2 adicionando a fundação. Não revisei propriamente e publiquei o arquivo, agora retornei e ainda tem problemas.

Software NUNCA está “finalizado”.

Mesmo isso que o Claude Code encontrou, não significa que corrige TUDO. Significa que corrige ALGUMAS COISAS. Nenhum software nunca tem “garantia” que está perfeito. Isso não existe.

Mesmo se tivesse começado com Claude Code, como falei antes, teria sim, sido mais rápido. Mas tudo depende do que você vai pedir pra ele. Se você não souber exatamente os requerimentos e especificações de segurança, ou performance, ou escalabilidade, ou mantenabilidade ANTES de pedir, ele vai fazer ALGUMAS COISAS. Não necessariamente as COISAS PERFEITAS, mas só ALGUMAS COISAS.

Daí alguém pode dizer “Tá vendo? Agora que revisou com Claude Code, vai estar perfeito”

Então, depois eu ainda pedi pro GPT 5.2 Codex fazer a mesma análise extensiva e adivinha: ele também encontrou mais probleminhas. Muito menos, claro. Mas veja bem, depois do GLM 4.7, do Opus 4.5, o GPT 5.2 ainda achou mais coisas. NUNCA ACABA!

Em particular, lembram como lá atrás eu tinha feito tokens serem encriptados, depois mudei o requerimento pedindo pra não ser e deixar in-memory no servidor? Ainda sobrou código antigo dessa funcionalidade. O GPT 5.2 achou que era pra terminar de implementar a encriptação e começou a colocar de volta. Tive que interromper e mandar ele parar e remover. Nem o Opus 4.5 removeu esse dead code.

Sempre, você que pede é o responsável por pedir exatamente e checar depois.

• 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.