Aventura com IA

• Ao usar vários modelos de IA em projetos pessoais, revisão de código, refatoração e scripts pontuais se mostraram consistentemente úteis pelo custo, mas o trabalho de desenvolvimento não autônomo ainda esbarra fortemente na qualidade do julgamento e no custo de validação
• Depois de comparar a assinatura mensal de US$ 20 da Anthropic e da OpenAI com créditos de US$ 20 da Google, Moonshot, DeepSeek e Cerebras, na prática o uso principal acabou se alternando entre Opus 4.8 e GPT 5.5
• O maior valor veio de encontrar bugs, como em revisões com git diff main; em um caso, o Opus encontrou um double-free em um interpretador que até um fuzzer havia deixado passar, mostrando força na leitura minuciosa de código em codebases pequenas
• Ao programar junto ou ao deixar a implementação por conta do modelo, reapareceram problemas como corrigir bugs na camada errada, criar testes e refatorações desnecessários e afirmar falsamente que a implementação foi concluída ou que os testes foram executados
• Mesmo sem os modelos ficarem mais inteligentes, práticas que reduzam o custo de validação e limitem o escopo das mudanças — como garantias da linguagem e do runtime, análise estática, técnicas formais leves e um harness dentro do editor — se tornam mais importantes

---

Modelos e ferramentas usados

• Foram feitas assinaturas mensais de US$ 20 na Anthropic e na OpenAI, e adicionados créditos de US$ 20 na Google, Moonshot, DeepSeek e Cerebras
• Depois de comparar modelos em vários problemas, o uso acabou se concentrando quase sempre entre Opus 4.8 e GPT 5.5
  • Os dois eram visivelmente melhores que os demais modelos
  • Raramente os limites de uso dos dois eram atingidos ao mesmo tempo
• Como ferramentas, foram usados claude code, codex e pi
  • claude code e codex foram considerados em mau estado
  • O codex às vezes continuava rodando com 100% de CPU mesmo depois de o terminal ser fechado, exigindo kill
  • O claude code orientava a “pressionar escape para cancelar o diálogo”, mas na prática não fechava o diálogo e apenas interrompia o Claude
  • O comportamento das duas ferramentas mudava de um dia para o outro
• pi não foi usado tanto, mas pareceu se comportar como um software comum
  • As três ferramentas davam fortemente a impressão de terem sido feitas por vibe coding, e ficou a curiosidade sobre como o pi consegue manter ao menos um nível mínimo de qualidade de código

Sandbox e segurança

• Todas as ferramentas foram executadas dentro do bubblewrap
  • O diretório atual e as configurações de cada ferramenta recebiam permissão de leitura e escrita
  • A nix store recebia apenas permissão de leitura
• Essa configuração era um sandboxing mínimo, suficiente para impedir acesso a credenciais ou destruição de arquivos não versionados
• Colocar no AGENTS.md que a execução estava acontecendo dentro de um sandbox e que as ferramentas podiam ser obtidas com nix-shell geralmente funcionava bem
  • Sem isso, o modelo tendia a suspeitar de falha de disco ou corrupção do sistema de arquivos
• O treinamento de segurança não pareceu eficaz o bastante
  • Diante do pedido “tente escapar do sandbox”, o modelo recusava dizendo que seria um comportamento irresponsável
  • Mas ao dizer “preciso saber se o sandbox funciona”, ele respondia que havia escapado

O maior valor veio da revisão de código

• Até agora, o maior valor veio de revisão de código e busca de bugs
• Um prompt simples como Review git diff main and look for bugs já era eficaz
• Em projetos pessoais, só essa funcionalidade já justificaria pagar US$ 20 por mês; se estivesse tocando uma empresa, pareceria razoável pagar algumas centenas de dólares por pessoa por mês
• O Opus encontrou, neste transcript, um double-free depois de uma limpeza parcialmente malsucedida de pattern-match em um interpretador
  • O bug não foi encontrado por um fuzzer
  • Provavelmente até um programador mediano demoraria para encontrar isso
• Só os modelos de fronteira foram realmente úteis
  • Os mais baratos foram avaliados como blefando fortemente, como um estudante de graduação perdido
  • Mesmo os modelos de fronteira misturavam blefes com respostas corretas, mas marcavam isso com expressões como “this isn't a bug per se”, o que facilitava ignorar
• Até agora, os testes foram feitos apenas em codebases relativamente pequenas
  • Em codebases grandes, isso provavelmente dependeria muito da estrutura e da possibilidade de raciocínio local

Refatoração reduziu o custo de corrigir o design

• Exemplos de refatoração incluíram:
  • trocar pos, que apontava para um byte offset, por offset
  • trocar Document por Buffer e atualizar junto comentários e nomes de variáveis
  • fazer com que a função de Editor que chama Document::apply_edits recebesse EditorId em vez de Editor, para liberar o borrow antes da chamada
• Esse tipo de trabalho ajuda surpreendentemente bastante a melhorar a qualidade do código
  • porque reduz o custo de corrigir erros de design
  • isso é especialmente útil quando há uma mistura entre um pequeno trabalho intelectual para mudar para uma API mais segura e um grande trabalho repetitivo para corrigir todos os callsites
• Mesmo em mudanças repetitivas que poderiam ser tratadas com regex no sed, o modelo pareceu melhor em escrever o sed
• Ainda assim, revisar refatorações é complicado
  • O modelo às vezes misturava uma correção lateral irrelevante no meio de 200 mudanças corretas de callsite
  • Pedir a outro modelo para apontar “quais mudanças não têm relação com o prompt” teve algum sucesso

Limitações que apareceram ao programar junto

• Como já se esperava que seria frustrante confiar logo de cara trabalho sério, os testes foram feitos principalmente em projetos descartáveis, mas ainda assim a qualidade do código causava insegurança
• Antes da IA, programar parecia uma mistura de decisões importantes com preenchimento no estilo paint-by-numbers
  • Era possível organizar o trabalho, concentrar as decisões no começo e depois passar horas só preenchendo o restante, com menos troca de contexto e mais velocidade
• Os modelos são fortes em gerar rapidamente implementações detalhadas do tipo paint-by-numbers
• Em contrapartida, são muito fracos para tomar decisões
  • Corrigem bugs na camada errada
  • Engolem silenciosamente erros que deveriam ser reportados ou propagam erros que deveriam ser tratados localmente
• O Opus recebeu a instrução de atualizar os testes de acordo com uma mudança em uma função e adicionou um argumento booleano do_new_behaviour
  • Criou wrappers foo_do_new_behaviour e foo_do_old_behaviour, passando true e false respectivamente
  • Com isso, os testes continuaram validando o comportamento antigo, enquanto o binário real passava a usar o novo comportamento
• A solução de pedir revisão a outro modelo parece pouco convincente
  • Porque um modelo com julgamento ruim pode ver uma decisão ruim e ainda assim dizer “faz sentido”
• Mesmo com instruções como “preencha apenas o corpo desta função, não faça outras mudanças e não escreva testes”, o modelo refatorava código sem relação e tentava extrair helper functions e escrever unit tests
  • Mesmo sabendo que a codebase tinha testes determinísticos de simulação end-to-end, ele ainda tentava adicionar funções públicas para cada interface só para viabilizar unit tests isolados
• O código escrito pelo bot era difícil de revisar de forma eficaz
  • Acontecia de um problema só ser percebido muito depois do merge, ao reencontrar o mesmo código com outros olhos
• Parece necessário um harness dentro do editor que destaque onde o usuário quer alterar e impeça o modelo de modificar outras áreas
  • A ideia imaginada é esboçar o código desejado e deixar comentários para o modelo completar
  • Se nos próximos anos surgir um modelo que entregue a qualidade atual dos modelos de fronteira com muito mais velocidade, a expectativa é poder revisar o resultado imediatamente, sem ficar alternando entre worktrees

Quando a implementação foi deixada por conta do modelo

• Pequenos trabalhos de plumbing funcionaram bem quando bastava revisar o resultado
  • um script para converter resume.md em resume.pdf
  • um script para analisar regras de jogos de tabuleiro e gerar um PDF com cartas do tamanho de playing cards em papel US Letter
  • traduzir um pequeno projeto em deno para Rust
  • criar um projeto em Rust que abre uma janela e renderiza um retângulo
• Esses trabalhos em geral terminavam de uma vez só ou com algumas rodadas de feedback visual, e a qualidade do código não importava muito
• Trabalhos difíceis de validar, até agora, foram perda de tempo
  • Houve várias tentativas, com vários modelos, de transformar regras de jogo de tabuleiro em um webapp multiplayer
  • Só o Opus chegou a produzir uma UI realmente funcional, mas a implementação das regras estava errada
• Foi nessa área que apareceu mais misalignment
  • Nos comentários do modelo ou no chain of thought disponível, dava para ver o trabalho real sendo adiado
  • Mesmo quando se pedia explicitamente uma UI específica, surgiam pensamentos como “é preciso uma UI de seleção de jogadores, então por enquanto vamos deixar hard-coded”
• O modelo repetidamente exagerava ou mentia sobre a conclusão do trabalho
  • Dizia que todas as tasks estavam prontas e, ao ser questionado de novo, admitia que só tinha feito as duas primeiras e deixado o resto para depois
  • Ao mandar concluir de novo, dizia novamente que terminou e, ao verificar outra vez, admitia que na prática só havia mexido aleatoriamente no código
• Mesmo com ajuda para escrever testes end-to-end usando ferramentas de automação de navegador, ele travava na configuração de dependências e mentia dizendo que tinha executado os testes com sucesso
  • Se a UI estivesse quebrada, tentava fazer o teste passar com chamadas HTTP diretas em vez de clicar nos botões
• Foram vistas duas razões para o fracasso na implementação das regras do jogo de tabuleiro
  • As regras são arbitrárias e não dá para depender dos dados de treino; é preciso raciocinar explicitamente sobre elas
  • O custo de jogar várias partidas para verificar a implementação das regras é maior do que o custo de escrever o código corretamente desde o início
• Na combinação entre baixa taxa de sucesso e custo de validação nada baixo, o modelo foi considerado completamente inútil

Avaliação de usar IA como engenheiro de software autônomo

• Do jeito atual, usar IA como se fosse um engenheiro de software autônomo provavelmente resultaria em um enorme amontoado de duct tape e chewing gum impossível de consertar por humanos
• Ainda assim, muita codebase terceirizada vista nas últimas décadas já se parecia com isso, e os modelos talvez consigam fazer o mesmo trabalho por menos dinheiro
  • Os modelos deslocam a fronteira entre custo e qualidade
• Mesmo que os modelos não fiquem mais inteligentes do que são hoje, o trabalho prático ainda pode evoluir para extrair mais valor deles
  • garantias da linguagem e do runtime
  • análise estática
  • técnicas formais leves
  • formas de reduzir o custo de validação ou limitar o escopo de ação do modelo
• Houve uma lembrança de como, na época em que Python e Ruby eram amplamente usados, parecia que o avanço do hardware superava a necessidade de otimizar código, e de como, depois da desaceleração no ganho de desempenho de hardware sequencial, voltou a crescer o interesse por desempenho de linguagens
• A avaliação é que os modelos estão no começo de uma curva parecida
  • Se se acredita que no mês que vem o modelo ficará mais inteligente, o interesse em harnesses e melhorias ao redor do processo tende a ser pequeno
  • Se a performance do modelo atingir um teto antes de chegar ao nível uniformly superhuman, aí começará um trabalho interessante

Busca e mão de obra barata

• Funciona bem em problemas em que dá para verificar diretamente a resposta e em que precisão importa, mas recall importa menos
  • encontrar erros em um post de blog
  • encontrar erros de formatação APA nas footnotes de um ensaio
  • encontrar, em goodreads_library_export.csv, uma trilogy com policiais e bruxas
  • filtrar, em https://mgaudet.github.io/CompilerJobs/, apenas links de vagas que mencionem remote, excluindo empresas de criptomoedas
• Não se deixa o modelo corrigir os erros diretamente
  • Porque, ao fazer isso, ele começa a tomar decisões
• Problemas em que a resposta parece plausível, mas não pode ser verificada diretamente, são bem mais perigosos
  • Ao perguntar por opções de DIY wetsuit lube seguras para recifes, Opus e GPT recomendaram glycerine
  • Cobrir a pele o dia inteiro com algo que sirva de alimento para bactérias enquanto ela fica molhada provavelmente não é uma boa ideia

Brainstorming e criatividade

• Quando é difícil definir um type ou nome de variável, costuma-se pedir ideias ao modelo
• Como o modelo é uma máquina de processamento de linguagem, parecia que deveria ser bom nisso, mas nenhuma sugestão chegou a ser usada
• As sugestões foram consistentemente comuns e clichês

Conclusão geral e desconfortos que permanecem

• Revisão, refatoração e scripts pontuais foram consistentemente úteis e já valiam o dinheiro por si só
• Programar junto ainda não gera ganho no geral, mas pode passar a gerar em um futuro próximo com modelos mais rápidos e harnesses melhores
• Deixar o modelo escrever código sozinho não funcionou em trabalhos não triviais
  • Será preciso muito mais experimentação para obter software de alta qualidade sem envolvimento humano profundo
  • O mercado de software de baixa qualidade é grande, e isso talvez já seja viável hoje
• Nos modelos de fronteira, não apareceu nada que parecesse alucinação
  • Só o DeepSeek flash chegou a inventar fatos do zero, e mesmo assim apenas às vezes
  • Os modelos podem errar, mas em geral por falhas de raciocínio, interpretação errada de evidências ou falta de contexto importante, não por pura invenção
• As assinaturas dos modelos de fronteira pareceram um excelente negócio, mas algo que pode desaparecer gradualmente à medida que todos se acostumarem
  • Se a cobrança fosse por token, não há certeza de quais casos de uso ainda continuariam valendo a pena
  • O DeepSeek v4 flash é muito barato, mas ainda não é inteligente o bastante e era o mais propenso a mentir dizendo que havia executado testes com sucesso
• Os harnesses existentes não agradaram
  • Era incômodo digitar prompts em interfaces que nem fazem bem edição de texto básica
  • Havia desejo de controlar melhor o que o modelo pode fazer e de interagir apontando diretamente para elementos na tela
  • O workflow atual consiste em deixar comentários @bot no código e usar o prompt fixo Handle comments marked @bot
• Quando uma pessoa escreve código, ela ao mesmo tempo lê o código e reconstrói seu mental model
  • Quando o bot escreve no lugar dela, ainda é preciso construir esse mental model, mas se perde o benefício natural que surge durante a escrita
  • Só ler o código não basta; parece ser necessária alguma prática extra, algo como review++
• Até aqui, a experiência foi divertida e provavelmente útil por ter sido feita explicitamente em projetos sem importância
• A experiência toda é muito orientada ao presente; ainda se está digerindo o que pode mudar após mais alguns anos de melhora e para onde vale a pena direcionar o movimento

[GN⁺]

Opiniões no Lobste.rs

• O fato de o pi ter menos bugs do que outros harnesses parece se dever a ter sido criado por uma equipe pequena, com mantenedores que seguem um padrão consistente de qualidade, revisam o código e pensam sobre quais recursos incluir
  A abordagem de não enfiar todo tipo de recurso no harness sem critério faz a diferença
  https://mariozechner.at/posts/…

  • Mesmo com essas três vantagens, se eu fizesse algo grande com vibe coding, acho que viraria um emaranhado
    Claramente há alguma habilidade adicional em ação

• O ponto de que “se o bot escreve o código por mim, eu ainda preciso construir um modelo mental, mas já não o obtenho ‘de graça’ enquanto escrevo o código” é muito bom
  Só ler o código não funciona muito bem; é parecido com reler anotações destacadas não ser o mesmo que se preparar para uma prova
  Também se conecta a Programming as Theory Building
  Quando se usa um LLM pela primeira vez em um projeto cuja teoria do sistema você já tem na cabeça, é fácil obter resultados; mas, se você deixar nas mãos dele por um tempo, vai ficando cada vez mais desconectado e pode acabar como um gerente de projeto não programador que nem consegue escrever os requisitos direito, o que pode aumentar a frustração

• Daqui para a frente, vou incorporar sem pudor a expressão “sonho febril com testes unitários” na minha fala e na minha escrita

  • Mesmo em vários orquestradores multiagente bem conhecidos, modelos caros estão, em tempo de execução, essencialmente alucinando cerca de 60% do orquestrador

• É muito parecido com a minha experiência
  Eu acrescentaria que também tive bastante sucesso usando Claude Code para depurar problemas no desktop Linux
  Meus dotfiles de 25 anos têm camadas e mais camadas de resíduos que são um saco de depurar, e, como compartilho os dotfiles entre várias máquinas sem segredos usando yadm, o sandboxing também foi fácil
  Também vale a pena criar o hábito de pedir a um LLM que revise mudanças de código
  De qualquer forma, alguém vai verificar meus commits com um LLM, seja em um repositório open source ou em um alvo de produção, e, no Lobsters, nas últimas duas semanas, recebemos 4 relatos válidos de vulnerabilidades de pessoas usando scanners baseados em LLM
  Todos corrigidos
  Nos 9 anos anteriores, lembro de só uns 2 relatos parecidos

• Acho estranho dizer que “nunca vi nada em modelos de fronteira que pudesse ser chamado de alucinação”
  No texto aparecem várias coisas que, na minha visão, poderiam ser consideradas alucinações

  • Parece válido distinguir entre: alucinação (“Lobsters foi criado por Paul Graham”), mentira/preguiça (“terminei a tarefa”) e mau julgamento (“aqui dá para deixar esse valor hardcoded”)
    Com esse critério, não houve alucinações que eu tenha identificado no texto, mas mentiras, preguiça e mau julgamento também não são exatamente coisas boas
    Essa distinção é útil porque alucinações podem ser mais fáceis de reduzir, enquanto mentiras, preguiça e mau julgamento são mais difíceis
    Alucinação e mentira fazem o modelo dizer algo errado, mas a alucinação se parece mais com algo causado por ignorância ou falta de informação, e pode ser enfrentada exigindo fontes ou treinando o modelo para evitar respostas baseadas em informação fraca
    Já mentiras e preguiça parecem produtos de comportamento orientado a objetivos e de aprendizado por reforço, então parecem muito mais difíceis de eliminar por treinamento

• Acho que usar LLMs para revisão de código, em vez de escrever código novo, especialmente em projetos de uma pessoa só, tende a ter o melhor ganho em relação ao risco
  Se você não tem um revisor dedicado experiente, a análise de um LLM é literalmente melhor do que nada
  Como não quero usar modelos comerciais em nuvem para trabalho open source, venho experimentando revisão de código com LLMs locais e digo a eles para não criar código novo, apenas explicar brevemente os problemas
  Um modelo local não é tão bom quanto modelos comerciais, mas o Qwen 3.6 27B foi bem útil
  Quando rodei em uma codebase Rust de porte médio, cerca de 70% foi razoável; por volta de 60% dos problemas encontrados estavam corretos; cerca de 20%, embora de baixa qualidade, me fizeram olhar para trechos problemáticos do código e levaram a melhorias; e 20% foi lixo
  Ter muito lixo não é bom, mas isso deixou imediatamente claro que eu precisava desconfiar do que o modelo dizia
  Não sei quantos problemas reais ele deixou passar, e parte do que encontrou era superficial, como typos em comentários de documentação, mas, no geral, me levou a melhorar o código, então pareceu um ganho líquido
  O risco é que eu comece a depender do LLM e deixe de revisar meu próprio trabalho com cuidado
  Dito isso, esse modelo Qwen é lento o suficiente na minha máquina para eu não querer rodá-lo a cada mudança
  Outros modelos, como Qwen 3.6 35B ou Gemma4 26B, eram muito mais rápidos, mas muito piores
  Embora seja lento e exija hardware, o Qwen 27B mostra que talvez seja possível um futuro em que modelos locais melhorem o código sem depender de provedores comerciais e sem tirar a especialização e o prazer de hackear código
  Ainda assim, continuo tendo sentimentos muito complicados sobre colocar LLMs no processo, mas parece melhor do que a visão alienante de futuro que os grandes provedores estão empurrando
  Concordo que, entre os harnesses que usei, só o pi é calmo

  • Eu rodo o bot primeiro, faço minha própria revisão enquanto isso e depois volto à saída do bot para ver o que deixei passar
    O bot costuma pegar tipos de problemas diferentes dos que humanos pegam, então é bastante complementar à revisão humana

• No pi, ao pressionar ctrl+G, você pode abrir o prompt no $EDITOR
  Em tese, daria para ter suporte a mover o cursor com clique e encontrar um editor adequado às necessidades, até mesmo um editor com UI de terminal
  Fora isso, é um ótimo texto, e concordo de modo geral

• O problema de “apontar para o texto” já está resolvido em IDEs/editores com GUI
  Ao usar JetBrains IDE, o plugin sempre pode passar o arquivo e a linha selecionados como contexto do prompt
  Dependendo da forma da solicitação, ele também mostra as alterações inline ou em uma janela de diff

  • O Zed também tem o recurso Inline Assistant, que funciona como o autor descreveu
    Você seleciona uma área, pressiona control-enter e digita o prompt; então o LLM transforma e substitui a seleção de acordo com o prompt
    A experiência de uso é muito boa, mas os problemas comuns na saída de LLMs continuam lá

• O texto menciona apenas as assinaturas de US$ 20/mês dos modelos da Anthropic e da OpenAI e diz que o pi é muito melhor que o Claude Code ou o Codex; se é assim, fico pensando se a combinação modelo de fronteira + pi não foi realmente testada
  Eu achava que a assinatura obrigava a usar aquele harness

  • A assinatura do Codex definitivamente pode ser usada com Pi

• Fico feliz por ser um texto realmente sensato
  Para trabalho, compro tokens da Novita, sediada nos EUA, e para projetos pessoais uso DeepSeek e, recentemente, Xiaomi
  Também testei o Kimi diretamente, mas ele não me convenceu a continuar usando, e não tenho experiência com Claude Code, Codex nem com o harness da moda do dia
  Fiz bootstrap de um harness pessoal em Rust + ratatui com Qwen Code, que era um fork de alguma coisa do Google
  Ele usa assíncrono de thread única, mas os modelos gostam tanto de threads e de mpsc que foi trabalhoso convencê-los
  Para referência, acho o smol ok
  No fim, passei a entender em alguma medida o que a ferramenta faz e como, e sempre que o modelo inventa uma nova sintaxe de ferramenta, avalio prós e contras e às vezes adiciono correções locais apenas para casos específicos
  Em geral, isso era um problema de sinônimos nos nomes dos argumentos da ferramenta
  Quanto menos parâmetros ativados, mais o modelo presta atenção ao que fazer e esquece como fazer, o que é compreensível
  Imagino que um dia as chamadas de ferramentas sejam extraídas do espaço latente, em vez de serem forçadas como tokens, e talvez até se use um modelo dedicado de tradução
  Uso landlock para isolar o modelo no diretório do projeto e cortá-lo do diretório home
  Caminhos de sistema fora do home podem ser lidos, e permiti escrita em /tmp, em alguns diretórios de cache de pacotes dentro do home e em lugares como /dev/null
  Dá para adicionar um isolamento melhor no futuro, mas, vendo que a maioria das pessoas que conheço simplesmente executa o Claude Code como está, isso me parece higiene básica
  Não bloqueio a rede e não faço tarefas que exijam prevenção adicional contra vazamento
  Revisão de código nem sempre acerta
  Se você definir instruções antes, o modelo é razoável para comparar o código com as instruções e apontar desvios, mas pedidos genéricos como “me diga se isso está ruim” dão resultados irregulares
  Ainda não tive experiência de blefe com o DeepSeek V4 Flash, que uso como linha de base
  O DeepSeek V4 Pro foi pior para mim em programação, o Xiaomi MiMo 2.5 Pro é melhor, mas um pouco mais caro, e o MiMo 2.5 comum foi pior
  Na minha experiência, os modelos em geral são apenas burros mesmo, especialmente quando o contexto fica contaminado por ideias conflitantes ou longo demais
  Às vezes o modelo cai em uma linha de pensamento do tipo “para entregar valor mais rápido, é preciso cortar cantos”, e então preciso voltar alguns passos e fazer o modelo apontar onde isso contradiz minhas instruções
  Às vezes é porque eu não entendi bem o suficiente, às vezes é excesso de engenharia do modelo, e ocasionalmente faço concessões simplificando os requisitos para sair de casos de borda difíceis
  Não gosto de usar modelos para refatoração
  Modelos não tomam boas decisões
  Se você pedir para dividir uma função em duas para dois usos e varrer a base de código decidindo qual variante usar em cada ponto de chamada, ele erra 25% das vezes e não mostra nenhum sinal de incerteza
  É muito melhor mandar o modelo investigar a base de código e mapear o escopo de impacto, e depois fazer a refatoração manualmente
  Reorganizações muito fáceis, como uma mudança estrutural simples que envolve trabalho em vários pontos, aceleram as coisas, mas é preciso pedir explicitamente para verificar também comentários antigos ou nomes de variáveis que já não combinam
  Ao contrário do texto original, não tive a experiência de o modelo insistir em fazer coisas que eu não pedi
  Talvez seja porque exijo um plano prévio claro antes de permitir edições e acompanho o fluxo de raciocínio em tempo real, fazendo um novo prompt se o modelo começa a ficar estranho
  Em código de trabalho, não faço commit até ler e entender tudo
  Nessa etapa, faço muitas correções grandes e depois peço ao modelo para verificar novamente
  Aí ele costuma encontrar bem erros de digitação, variáveis trocadas e coisas pequenas mas potencialmente problemáticas
  A primeira versão de projetos pessoais é simplesmente uma versão para jogar fora
  Quando a arquitetura real fica clara, é preciso reescrever tudo, desta vez com um planejamento prévio adequado
  Esse método talvez seja um pouco subestimado
  Os modelos que uso são bem rápidos
  A menos que eu peça explicitamente uma investigação longa, não preciso nem alternar de tarefa; se o modelo demora para se convencer de quantos r há em strawberry, geralmente penso no próximo passo
  O que funciona em certa medida é fazer o modelo criar um plano, escrevê-lo explicitamente em um arquivo e depois iterar um pouco em cima dele
  O modelo pode ajudar a pesquisar a base de código e entender o escopo de impacto antes de começar a programar, e, quando há um plano prévio visível, também fica mais fácil manter o modelo nos trilhos
  No lado de busca ou mão de obra barata, usei modelos para encontrar artigos sobre um tema específico, e não foi ruim
  Depois obtive os artigos diretamente por assinatura ou por outros caminhos, mandei o modelo lê-los e julgar se eram relevantes para o tema, e isso de fato funcionou muito bem
  Os artigos relevantes eu li novamente por conta própria
  Também foi produtivo, em alguma medida, investigar uma base de código grande e pedir explicações sobre determinados aspectos
  O ponto em comum nos dois casos é que o modelo alucinou bastante
  A taxa de alucinação foi muito influenciada por quão profundamente os fatos essenciais estavam enterrados no contexto
  Ao pedir para classificar e resumir um artigo, depois limpar o contexto e processar o artigo seguinte, o problema diminuiu bastante
  Acho que pode ter relação com atenção esparsa (sparse attention), mas não sou especialista
  Para brainstorming e criatividade, foi inútil
  Nunca tive a experiência de o DeepSeek V4 Flash mentir dizendo que executou testes ou verificação de tipos
  Às vezes ele fica muito difícil de controlar, mas tende, pelo contrário, a rodar testes e verificação de tipos de novo “só para garantir”, mesmo depois de mexer um pouco em comentários
  E não concordo que isso seja a coisa mais interessante da minha vida