0804 | Dez avanços da OpenAI, CVEs em SQLite e o gap de produtividade

Sofia Almeida: Bem-vindos ao Hacker News diário, o podcast da Bri. Eu sou a Sofia Almeida.

Rafael Costa: E eu sou o Rafael Costa. Hoje temos um episódio recheado: começamos pelos avanços da OpenAI em matemática e ciência da computação teórica, e ainda falamos sobre uma vulnerabilidade crítica no SQLite.

Sofia Almeida: Também vamos discutir o paradoxo da produtividade com IA, o efeito Dunning-Kruger, e o projeto que pode ser o maior já feito em código aberto.

Rafael Costa: E isso é só o começo. Vamos também falar de modelos de vídeo, ferramentas de desenvolvimento open source, e os vinte anos do Pandoc. Fica com a gente!

Sofia Almeida: Então, a OpenAI publicou um artigo anunciando dez avanços em matemática e ciência da computação teórica, e o que chama atenção é quem teria feito esse trabalho: uma versão interna do Astra, o próximo grande modelo da empresa. Cada resultado atacaria problemas em aberto em áreas como geometria de altas dimensões, teoria de códigos, complexidade de circuitos e até criptografia de reticulados.

Rafael Costa: E o custo, segundo a empresa, foi de cerca de dois mil dólares em tokens, considerando as taxas da API deles. Cada argumento ainda foi formalizado num certificado Lean, então não é só uma afirmação — eles liberaram inclusive uma narração do processo de pensamento do modelo.

Sofia Almeida: Isso não é totalmente inédito. Em maio, a OpenAI já tinha compartilhado uma refutação gerada por IA da conjectura de Erdős sobre distâncias unitárias. E o artigo também menciona o ChatGPT for Academic Researchers, que dá acesso gratuito aos melhores modelos para cem mil cientistas e matemáticos.

Rafael Costa: O que me chamou atenção foi a discussão na comunidade. Um usuário no Hacker News discordava do que chamou de dread existencial dos matemáticos, dizendo que cada conjectura derrotada abre sete ou oito ideias novas — e que o caminho continua sendo definido por matemáticos humanos. Outro contra-argumentou que a questão real é mais sobre velocidade do que sobre a matemática em si.

Sofia Almeida: E o artigo ainda defende uma atribuição de autoria honesta: a OpenAI assume responsabilidade pela correção dos manuscritos, mas reconhece abertamente que os argumentos foram gerados pelo sistema.

Rafael Costa: Agora essa é a história de um jornalista, Joel Feder, do site The Drive, que foi parado por quatro policiais num estacionamento, cercado junto com a esposa. O gatilho? As câmeras de placas da Flock Safety tinham rastreado o Range Rover dele, de cento e cinquenta e cinco mil dólares. A parada, segundo a própria investigação de Feder, começou com um erro humano.

Sofia Almeida: Um policial teria digitado errado um número de placa incompleto no banco de dados do FBI, o National Crime Information Center. Esse banco alimenta os leitores automáticos de placa de empresas como Flock, Leonardo e Axon. E o texto afirma que a Flock não tem banco próprio — ela puxa do banco de dados do FBI, que tinha recebido informação incorreta e parcial. As câmeras, operando com IA, teriam agravado tudo de forma exponencial.

Rafael Costa: E o detalhe: o CEO da Flock, Garrett Langley, concedeu uma entrevista ao Feder justamente no meio dessas reações e na época em que as câmeras geraram essa abordagem. No podcast, Langley disse que nada o deixaria mais feliz do que uma regulação estadual, estado por estado, desse tipo de tecnologia — e que a falta dela mostra que os eleitos precisam se mover mais rápido do que fizeram historicamente.

Sofia Almeida: Isso é irônico, dado que ele mesmo já tinha chamado quem vandaliza ou destrói os equipamentos da Flock de terroristas domésticos. E o artigo relata o contexto todo: policiais usando a tecnologia para perseguir pessoas, prisões, situações mal interpretadas, discussões em câmaras municipais, e leitores de placa cortados, baleados ou cobertos com sacos de lixo. Uma história sobre vigilância, erro humano e um erro inicial de digitação que quase virou uma parada policial.

Sofia Almeida: Agora uma história que os times de segurança vão reconhecer na hora. A empresa JFrog publicou uma análise sobre um lote de avisos de vulnerabilidades do SQLite. Um repositório GitHub recém-criado distribuía esses avisos, parte de um grupo maior de mais de cinquenta CVEs — e a conclusão deles é que quase tudo era, como diz o título, LLM slop. Lixo de modelo de linguagem.

Rafael Costa: Mas com uma exceção. E o que pesa é que o NVD, o banco nacional de vulnerabilidades, marcou rapidamente essas CVEs como críticas, e o ADP da CISA concordou. Só que a verificação da JFrog desmontou as alegações: o código citado não existia nessas versões, ou referia lógica não relacionada; os PoCs não funcionavam, sem causar crash; nenhuma dessas CVEs está na página oficial de avisos do SQLite; e os textos parecem gerados por IA.

Sofia Almeida: Na discussão, um usuário resumiu o problema real: isso vai ser um pesadelo para organizações que são obrigadas a corrigir todas as CVEs. O autor da submissão disse que o primeiro pensamento dele foi exatamente esse — que isso pode ser terrível se usado de forma ofensiva, e que a melhor defesa seria um agente reproduzir os problemas antes de um humano ver, mesmo que isso custe dinheiro.

Rafael Costa: E a conversa ficou ainda mais interessante. Um usuário respondeu que, se terrível quiser dizer incrível, seria possível derrubar uma torre Jenga inteira de corpospeak — essa burocracia de conformidade — e substituí-la por segurança real. Outro perguntou que organização real teria essa política de corrigir tudo, sem autoengano ou banindo todo open source. E aí alguém respondeu com uma sigla: ITAR. E mais um lembrou que muitas organizações, especialmente com certificações ISO 27000, têm exatamente essa política de gestão de vulnerabilidades.

Rafael Costa: Por fim, um ensaio sobre o famoso paradoxo da produtividade com IA. O engenheiro e líder de engenharia Bjorn Roche escreveu no blog dele, em julho, que a IA melhorou a produtividade das equipes e vai melhorar mais — mas que construir features de produção ainda parece levar quase o mesmo tempo de antes, enquanto alguns líderes esperam que features completas saiam na velocidade de protótipos.

Sofia Almeida: O argumento central dele é ótimo: codar não é onde os desenvolvedores gastam a maior parte do tempo. Engenheiros seniores gastam muito tempo decidindo qual código precisam escrever, e a IA ainda não facilitou essa parte. Às vezes ela até atrapalha: ler um documento de requisitos de produto ou um ticket escrito por IA demora mais do que revisar um documento humano, porque a escrita da IA pode ser excessivamente detalhada, difícil de destilar.

Rafael Costa: Ele montou um dia de oito horas para ilustrar. Para um dev sênior, o tempo de escrever código novo cai de uma hora e meia para meia hora, e leitura e debugging caem de uma hora e meia para uma hora. Mas design e arquitetura continuam com uma hora, code reviews continuam, documentação continua. E algumas coisas até sobem: testes, CI e deploy passam de meia hora para quarenta e cinco minutos, porque há mais código novo. O total vai de oito horas para seis e meia.

Sofia Almeida: Mesmo supondo codificação três vezes mais rápida, o sênior economiza uma hora e quinze minutos por dia, cerca de quinze por cento. Já para um júnior, a queda na escrita é maior — de duas horas e quarenta e cinco para uma hora — mas o pesadelo mesmo fica em tudo que envolve leitura, revisão e integração. Ou seja, a IA acelera onde os desenvolvedores já eram rápidos, e toca pouco no trabalho que realmente consome o dia. O que talvez seja a lição mais honesta sobre o gap de produtividade.

Sofia Almeida: Então, qual é o maior projeto de software que a inteligência artificial consegue completar sozinha? Essa pergunta é a base de um benchmark novo chamado MirrorCode, criado pela Epoch AI em parceria com a METR. A ideia é simples de explicar, mas difícil para a máquina: o modelo precisa reimplementar um programa inteiro, do zero e de ponta a ponta, sem ter acesso ao código-fonte original. E não basta ficar parecido — as soluções têm que bater exatamente com a saída do programa original nos testes, inclusive nos testes que ficam escondidos do modelo durante o desenvolvimento.

Rafael Costa: São 25 programas-alvo no total, cobrindo desde utilitários Unix e ferramentas de consulta até bioinformática, interpretadores, análise estática, criptografia e compressão. Mas o verdadeiro diferencial é o orçamento de inferência. Em benchmarks tradicionais, o gasto costuma ficar entre um e dez dólares. No MirrorCode, uma das maiores tarefas chegou a custar 2.600 dólares em uma única execução, com a inteligência artificial trabalhando 19 dias sem nenhuma intervenção humana.

Sofia Almeida: E olha a segurança disso: os agentes ficam em uma sandbox, sem internet, sem acesso ao código original e sem ver os testes escondidos durante o trabalho. Isso impede que eles criem atalhos ou tabelas de consulta. A estimativa é que um engenheiro humano, sem ajuda de IA, levaria meses nas tarefas mais complexas.

Rafael Costa: O exemplo principal é impressionante. O modelo Claude Opus 4.7 reimplementou o gotree, um toolkit de bioinformática com cerca de 16 mil linhas de código em Go e mais de 40 comandos, em 14 horas, ao custo de 251 dólares. Para um humano sem IA, a mesma tarefa levaria de duas a 17 semanas. E o detalhe que mostra o quão perto do acerto total ele chegou: passou em dois mil de dois mil e um testes, falhando apenas num caso de borda de um único comando.

Sofia Almeida: Ou seja, não estamos mais falando de modelos que escrevem snippets ou funções isoladas. Estamos falando de programas inteiros, dos utilitários do sistema à compressão, concluídos de forma autônoma — com meses de trabalho humano comprimidos em horas.

Rafael Costa: Deixa eu te fazer uma pergunta: quando alguém se sai mal numa tarefa, todo mundo logo cita o Efeito Dunning-Kruger, certo? Pois bem, um artigo da McGill University, que circulou por aqui, defende que esse efeito provavelmente não é real — que pode ser apenas um artefato dos dados.

Sofia Almeida: E a reação da comunidade foi quase unânime: bom, isso parece mais uma pegadinha para fazer o autor provar o próprio ponto contra quem cita o efeito para todo lado. Um comentarista na thread perguntou, meio incrédulo: então isto é um caso do Efeito Dunning-Kruger? E outro respondeu na mesma linha, dizendo que o artigo parece fazer de tudo para defender sua tese particular, mas que a leitura acaba sendo justamente disso.

Rafael Costa: A ironia é perfeita aqui. A teoria clássica diz que quem é incompetente num domínio tende a superestimar suas habilidades — justamente por não ter competência para julgar o próprio desempenho. Se alguém aponta o Dunning-Kruger para explicar por que os outros interpretam mal o estudo que questiona o Dunning-Kruger... bom, a discussão se fecha num loop.

Sofia Almeida: Depois vem só o comentário que consegui ver até aqui, mas já dá para sentir o clima da thread: uma mistura de ceticismo de quem lê o método com atenção e humor de quem percebe que a conversa está andando em círculos.

Sofia Almeida: Sabe aquela ideia de que LLMs transformam todo mundo em generalistas? Que qualquer um consegue um resultado mais ou menos ok delegando tudo ao modelo? Pois o ensaio de Sean Goedecke, chamado LLMs reward expertise, confronta exatamente isso. A tese central dele é que os modelos recompensam quem tem expertise no domínio — e não o contrário.

Rafael Costa: A provocação dele é clara: muita gente acha que não há habilidade nenhuma envolvida em usar um LLM, e que um "prompter habilidoso" teria os mesmos resultados que um novato, já que todos estão falando com os mesmos modelos. Goedecke discorda. E a ilustração principal ele pega de ninguém menos que o matemático Terence Tao, conversando com o ChatGPT sobre um contraexemplo recém-descoberto para a Conjectura de Jacobian.

Sofia Almeida: E as observações dele sobre as mensagens do Tao são reveladoras. As mensagens são curtas e diretas, respondendo ao grosso e não ponto a ponto. As respostas que o modelo dá são bem mais concisas do que quando o próprio autor discute matemática com o GPT. Ao sinalizar expertise, o Tao coloca o modelo em modo "falar com matemáticos", e não "explicar para amadores".

Rafael Costa: Ele também questiona respostas que parecem erradas sem contradizer diretamente — tipo dizer que aquilo parece mais complexo do que esperava. E ele mesmo faz saltos e sugestões, quase nunca seguindo o conselho do modelo sobre para onde ir. A chave, segundo Goedecke, é entender a matemática: extrair a ideia relevante da resposta, sugerir abordagens alternativas e identificar o que parece estranho.

Sofia Almeida: E ele diz que vale o mesmo no trabalho dele de código. Com um bom modelo mental do codebase, você consegue empurrar o LLM muito mais longe — tipo responder "não, acho que dá para fazer de outro jeito". Ou seja, a ferramenta não apaga a expertise. Ela amplifica quem já sabe o suficiente para guiá-la.

Rafael Costa: Agora uma boa notícia vinda da Alemanha: pela primeira vez, a energia eólica e a solar ultrapassaram os combustíveis fósseis no país, de acordo com uma matéria da bne IntelliNews. E a discussão no Hacker News mostra que o marco merece comemoração, mas também pede um pouco de contexto.

Sofia Almeida: O primeiro comentarista fez exatamente esse contraponto: é ótimo e é um marco a celebrar, mas se você contar toda a energia — e não só a eletricidade, e não apenas o mundo desenvolvido — o progresso não é tão rápido. Ele mencionou ter visto um post, baseado em dados da Our World in Data, argumentando que as renováveis seriam irrelevantes e que os fósseis continuariam sendo a principal fonte para a vida toda.

Rafael Costa: Mas aí vem uma resposta técnica importante. Ao olhar um gráfico desses, é preciso lembrar que queimar hidrocarbonetos é relativamente ineficiente: só cerca de 20 a 30% da energia do combustível vira trabalho útil, enquanto a eletricidade é muito mais eficiente — então precisaríamos de muito menos dela. Ainda há um longo caminho, diz o comentarista, mas é menos sombrio do que parece. E o crescimento exponencial de eólica e solar é difícil de enxergar num gráfico de curto prazo que só vai até 2024.

Sofia Almeida: E tem uma projeção ousada nessa exponencial: as renováveis chegariam perto de 100% da eletricidade no início a meados dos anos 2030, e aproximadamente 100% de toda a energia no fim dos anos 2030 a início dos anos 2040 — isso sem contar o ganho de eficiência do uso direto da eletricidade.

Rafael Costa: Claro, tem sempre o "depende". As melhores usinas de ciclo combinado chegam a uns 60% de eficiência; um motor a gasolina de carro, no caso ideal, fica por volta de 45%, mas no mundo real, dirigindo, cai bastante. Ou seja: a fotografia dos dados de hoje é mais conservadora do que a trajetória sugere — e o marco alemão é um bom sinal de que essa curva está se sustentando.

Sofia Almeida: A MiniMax acabou de lançar o H3, um modelo de vídeo de pesos abertos, e o suporte nativo no ComfyUI já chegou no mesmo dia. A proposta é ousada: um modelo que recebe texto, imagem, vídeo ou áudio e gera vídeo com som estéreo real, em até 2K e com clipes de até 15 segundos.

Rafael Costa: E é a terceira geração da MiniMax, depois do Hailuo 01 e do Hailuo 02 — mas o primeiro com pesos abertos. Entre os modos dá para ir de texto para vídeo, de imagem para vídeo, controlar o primeiro e o último frame, e até transferir movimento e editar no lugar.

Sofia Almeida: O que chama atenção é a otimização de memória. Em precisão total, o modelo usava cerca de 123 gigabytes; nas variantes menores, com offloading dinâmico de VRAM, essa pegada cai para 42 gigabytes e meio — uma redução de 66%. Em tese, dá para rodar localmente numa GPU doméstica como a RTX 3060.

Rafael Costa: E a comunidade está reagindo forte. Um dos comentaristas disse que viu as amostras e imediatamente apagou as pastas dos concorrentes LTX2 e WAN — "completamente inúteis agora", nas palavras dele — embora reconheça que há debate sobre a licença nos Estados Unidos, no Reino Unido e na União Europeia.

Sofia Almeida: Outro usuário ironizou justamente esse aviso de que regiões como a UE, o Reino Unido, a Coreia do Sul e os EUA estão desenvolvendo ou aplicando regulações de IA para modelos generativos de vídeo — ele brincou que basta prometer de dedinho não irritar a Disney para conseguir a licença.

Rafael Costa: Enquanto isso, há quem veja Hollywood em alerta vermelho, e também quem desconfie: um comentarista acha que o vídeo de exemplo parece arte altamente produzida, de TV, comerciais e jogos, e considera difícil acreditar que o modelo não foi treinado nesses materiais. O entusiasmo, portanto, anda dividido entre impressionados e céticos.

Sofia Almeida: Do mundo dos modelos de vídeo para a segurança ofensiva: temos o Nightcrawler, um agente autônomo de teste de penetração, open-source, que roda inteiramente dentro de um smartphone Android. O criador, NickySlicks, conta que o projeto começou justamente com a pergunta: quanto de um fluxo real de pentest dá para executar localmente em hardware móvel relativamente antigo, sem depender de nuvem ou API?

Rafael Costa: E a resposta deles foi usar um modelo de 1,2 bilhão de parâmetros rodando na GPU Adreno de um OnePlus 8. O modelo escolhe os alvos e as ferramentas, mas há um proxy separado que valida cada comando antes da execução, garantindo que tudo fique dentro do escopo combinado.

Sofia Almeida: O sistema guarda memória por host em SQLite, compara versões detectadas com uma base local de CVEs, executa playbooks de múltiplas etapas e gera um relatório estruturado ao final. E há também um modo de ensaio, só para testar o loop do agente sem executar comandos reais de rede.

Rafael Costa: Como o modelo é pequeno, ele só produz um comando utilizável cerca de metade das vezes. Então boa parte da engenharia é lógica de recuperação, detecção de duplicatas, memória persistente e playbooks determinísticos para compensar isso. A inferência local roda em torno de 115 tokens de prompt por segundo e 13 tokens gerados por segundo.

Sofia Almeida: O autor afirma que o sistema está rodando na rede doméstica dele há três meses sem interrupção. E, respondendo a perguntas, ele revelou que só testou o agente contra quatro redes autorizadas — uma delas corporativa. Deixou o sistema rodando a noite inteira e ele encontrou apenas um CVE menor, com uma semana de idade, que ele supõe que a equipe de TI já tinha no rastreador.

Sofia Almeida: Mudando de assunto: David Crawshaw publicou um ensaio chamado "Devtools must be open source", defendendo que os agentes de IA mudaram completamente o retorno sobre o investimento em personalizar software. Ele conta que, cinco anos atrás, a maioria dos engenheiros que entrevistou — em parte para entender como o Tailscale poderia se encaixar na vida deles — não tinha nenhum programa escrito por eles mesmos.

Rafael Costa: Ou seja, usavam programas de outros para escrever programas para outros. Escrever software próprio tinha retorno duvidoso, e a manutenção depois de um ano era dolorosa demais. A tese dele é que existem duas categorias de prompt que tornam a personalização viável hoje em dia.

Sofia Almeida: A primeira: baixar o código-fonte, compilar para uso local, modificar e registrar no controle de versão a motivação original da mudança. A segunda: um cron job noturno que busca mudanças upstream, faz rebase das mudanças locais, verifica se o software continua funcionando como esperado e substitui a versão atual.

Rafael Costa: Esses prompts podem ser embutidos no agente como uma skill — e o artigo afirma que isso foi incorporado ao Shelley. Com isso, um comando simples como "deixa a interface do Shelley com alto contraste" personaliza o agente sem exigir programação.

Sofia Almeida: E o ponto central ganhou apoio do Simon Willison, o simonw. Ele sustenta que a liberdade de examinar e modificar software sempre foi o argumento do open source, mas a realidade para a maioria das pessoas — mesmo programadores experientes — era depender de outros para exercer essa liberdade. Com os modelos de linguagem, a equação mudou: várias vezes por dia ele pede ao Claude para clonar um repositório do GitHub e explicar o código. A liberdade deixou de ser teoria, e virou prática cotidiana.

Sofia Almeida: E para fechar, um projeto chamado Octane, descrito como "o modelo de programação do React, compilado". Ele se apresenta como sucessor do Inferno, com a mesma meta de performance: hooks, Suspense e actions do React compilados antecipadamente, sem virtual DOM, sem rules of hooks e sem arrays de dependência mantidos à mão — o compilador deduz o que o código captura.

Rafael Costa: A grande promessa é que o.tsx comum continua funcionando, permitindo migrar componentes um a um para a extensão do Octane. E, via uma camada de compatibilidade, quase tudo de um app React 19 cruza de boa — a única exceção são os React Server Components. Hooks, Suspense, contexto e renderização no servidor vêm junto.

Sofia Almeida: Na tabela de comparação, o Octane aparece como referência em 1 vez, e os concorrentes aparecem como múltiplos relativos — menor é melhor. Vue Vapor e Ripple ficam no mesmo 1,0, Solid vem logo atrás, e React 19 aparece em 2,5 vezes.

Rafael Costa: E é aqui que a discussão esquenta. Um comentarista reparou que Vue Vapor e Ripple mostram o mesmo desempenho do Octane, mas com barras visualmente mais longas — e chamou isso de "classic statistics dark pattern", como se o time do Octane quisesse justificar colocar a própria implementação no topo. Um dos mantenedores respondeu que eles só rodam um script que executa os benchmarks e atualiza o gráfico, que os números são arredondados, e que foram o mais honestos possível — para ele, não há sentido em manipular isso. No fim, o ceticismo e a transparência continuam brigando de igual para igual.

Sofia Almeida: Começamos pelos vinte anos do Pandoc. John MacFarlane, o criador, relembra que a primeira versão saiu em 3 de agosto de 2006, sob licença GPL. O Pandoc 0.1 tinha cerca de três mil linhas de código em Haskell, sem nenhuma dependência além da biblioteca padrão, e já convertia Markdown, reStructuredText, HTML e LaTeX entre si, além de RTF e S5.

Rafael Costa: E olha o tamanho que isso virou. O texto conta que o projeto passou de duzentos lançamentos, suporta mais de cinquenta formatos de documento, foi integrado ao Quarto e ao Jupyter Notebook, está instalado em milhões de computadores e se tornou o programa mais popular escrito em Haskell.

Sofia Almeida: O detalhe curioso é que MacFarlane diz que decidiu aprender Haskell primeiro — a partir do blog do lógico Greg Restall — e só depois escolheu escrever um conversor de documentos. Em vez das transformações por regex que as implementações da época usavam em Perl, Python, Ruby e PHP, ele montou um parser de Markdown baseado em parser combinators e numa árvore sintática abstrata. O gancho é que, com N leitores e M escritores, você obtém N vezes M conversões possíveis.

Rafael Costa: E tem marcos bonitos no caminho. Em outubro de 2006, o desenvolvedor turco Recai Oktaş empacotou o Pandoc para o Debian. A versão 0.3 trouxe o writer DocBook e a sintaxe de notas de rodapé. A 0.4 adicionou tabelas, listas de definição, super e subscrito, tachado e listas ordenadas, além de writers para man pages e ConTeXt, com a estreia no Hackage.

Sofia Almeida: E chegamos ao Pandoc 1.0, em setembro de 2008, que já vinha com writers para MediaWiki, GNU Texinfo, OpenDocument e ODT, e blocos de código cercados com realce de sintaxe. E tem mais um detalhe que mostra a dedicação dele ao ecossistema: para suprir lacunas do Haskell, MacFarlane acabou criando também pacotes próprios — e é ali que a história continua.

Rafael Costa: Mudando de assunto no todo, tem uma discussão curiosa no Hacker News a partir de um artigo da Cloudflare sobre rodar os modelos Kimi e GLM em escala, com foco em deixar a inferência menor, mais rápida e mais segura. Mas o debate técnico quase passou despercebido, porque o que pegou foi a suspeita de que o próprio post seria texto gerado por IA.

Sofia Almeida: Exatamente. Um comentarista disse que se interessou pela leitura até que o "detector de slop" dele disparou num parágrafo específico — o que começa com a frase de que vale a pena ser preciso sobre de onde vem o benefício, porque não é velocidade bruta. Ele afirma amar IA, mas odeia lê-la. Outro respondeu que precisou parar de fazer esse tipo de comentário porque ele apareceria em metade dos posts, e gostaria de poder sinalizar prosa como gerada por IA e filtrá-la.

Rafael Costa: E surgiram soluções práticas. Um comentarista lembrou que o LinkedIn, de todos os lugares, anunciou recentemente um botão para sinalizar esse tipo de conteúdo, embora não tenha certeza de como funcionaria no Hacker News. Outro indicou o Pangram, uma extensão de navegador que cobre X, Reddit e Substack, com mais plataformas por vir.

Sofia Almeida: Teve até quem escrevesse um pequeno script que raspa os comentários para ver se alguém já classificou o artigo como IA e, se sim, esmaece o artigo. E um comentarista pediu para ninguém parar de comentar sobre o assunto, justamente para que publicar slop passe a ser visto como algo sem graça.

Rafael Costa: Também houve reclamação de que os comentários são cobrados por um padrão mais alto que as submissões, citando a diretriz do HN de que o site é para conversa entre humanos. E outros comentaristas discordaram desse foco — e é nesse meio do embate que a conversa continua.

Sofia Almeida: E chegamos ao fim de mais um mergulho no mundo da tecnologia e da pesquisa. Passamos por avanços da OpenAI em matemática e ciência da computação teórica, pela discussão sobre o Dunning-Kruger, pela produtividade com IA, e ainda vimos modelos de vídeo com pesos abertos, projetos open-source e a história dos vinte anos do Pandoc.

Rafael Costa: Foi um programa completo, né? De sistemas de IA até ferramentas de desenvolvimento. Obrigado por acompanharem até aqui — e não deixem de comentar, discutir e questionar tudo o que ouvimos hoje.

Sofia Almeida: Até a próxima!