0918 | Software enxuto e IA a toda velocidade

||Download

Show notes

Neste episódio, o que está a mudar no software e na IA: modelos mais pequenos e eficientes, agentes de código, segurança que mais importa do que caçar falhas, ferramentas que redesenham o dia-a-dia dos devs, e até o que os centenários japoneses têm a ver com dados. Tudo em poucos minutos.

Linha do tempo

  • 00:00:04 Abertura
  • 00:00:51 Modelos mais eficientes e o novo ciclo da investigação em IA
  • 00:08:01 Ferramentas e agentes que mudam o trabalho de código
  • 00:12:30 Segurança: vazamentos, limites e prioridades
  • 00:15:34 Para onde vai o esforço: prioridades e métodos
  • 00:19:44 Sistemas e projetos da comunidade
  • 00:24:50 Retratos sociais: longevidade, armazenamento e encontro
  • 00:27:43 Encerramento

Links relacionados

Este episódio é produzido pela Bri. O Bri usa tecnologia avançada de IA para transformar os feeds importantes para você em podcasts feitos para ouvir. Fale conosco em hi@bri.so.

Transcript

Sofia Almeida: Boa tarde, aqui está a Sofia Almeida.

Rafael Costa: E o Rafael Costa, bem-vindos ao podcast. O dia de hoje tem um fio condutor muito interessante: ferramentas que prometem fazer mais com menos — modelos mais pequenos e eficientes, agentes que portam sessões entre si, motores de busca que só procuram no que você já viu.

Sofia Almeida: E também o outro lado: o que acontece quando essas ferramentas se espalham — vazamentos de código, rate limits, e a pergunta de onde é que devemos gastar o esforço de segurança e de engenharia. Vamos começar pelo que talvez seja a notícia técnica mais falada das últimas vinte e quatro horas: um modelo de vinte e sete mil milhões de parâmetros que cabe num ficheiro de menos de seis gigabytes.

Rafael Costa: Sim, a PrismML lançou o Ternary Bonsai 2 27B. O nome já diz muito: usa pesos ternários, ou seja, os pesos não são números de precisão completa, são essencialmente valores de um conjunto muito reduzido — algo como negativo, zero e positivo. Isso comprime o modelo de uma forma dramática: 5,9 gigabytes no total.

Sofia Almeida: E o desempenho? Segundo a própria PrismML, o modelo atinge 98,2 por cento dos benchmarks do Qwen3.8-27B. Ou seja, está muito perto do modelo de referência de tamanho equivalente, com uma fração da memória.

Rafael Costa: E há dois detalhes que merecem destaque. Um: contexto de 262 mil tokens, o que não é nada típico num modelo tão comprimido. Dois: a licença é Apache 2.0, portanto é aberto e pode ser usado comercialmente.

Sofia Almeida: Aqui é onde a conversa fica interessante, porque a reação das pessoas divide-se em dois campos. De um lado, os entusiastas: um modelo de 27B que corre em hardware modesto, com contexto gigante e licença permissiva, muda completamente quem pode experimentar coisas sérias localmente. Se aquilo que prometem se confirma, deixa de ser necessário um cluster para fazer inferência decente.

Rafael Costa: Do outro lado, os céticos — e são uma parte importante da discussão. A pergunta que aparece repetidamente é: 98,2 por cento de quê exatamente? Benchmarks são escolhidos, e há uma longa história de modelos que brilham nos testes publicados e decepcionam no uso real. Sem comparações independentes, o número é uma afirmação do fabricante.

Sofia Almeida: E há uma segunda ordem de ceticismo que eu acho mais profunda: o custo dos pesos ternários não está na precisão, está no treino. Treinar com quantização extrema costuma exigir truques complicados — que quase nunca são explicados por inteiro. A PrismML publicou os pesos, mas a questão de como se chegou lá, e se terceiros conseguem replicar o processo, fica em aberto.

Rafael Costa: E mesmo que tudo seja verdade, há a pergunta da generalização: será que esta abordagem ternária escala para modelos maiores, ou funciona apenas nesta janela de tamanho? Isso não está respondido. O que está respondido é que se os números aguentarem, a inferência local acaba de ficar muito mais acessível.

Sofia Almeida: Do modelo que comprime tudo para algo quase oposto: um artigo no arXiv, o 2609.18842, que propõe um LLM de parâmetros infinitos. A ideia é radical: em vez de ter pesos fixos guardados num ficheiro, uma hypernetwork gera os pesos em tempo real, a partir dos dados de interação, com atualização bayesiana online.

Rafael Costa: Vale a pena parar um segundo nisto, porque é uma mudança conceptual. Num modelo normal, o treino acaba e os pesos ficam congelados; a aprendizagem depois disso é limitada a coisas como contexto ou fine-tuning ocasional. Aqui, o modelo está teoricamente sempre a aprender: cada interação alimenta a atualização bayesiana, e a hypernetwork produz os pesos para o próximo passo.

Sofia Almeida: As reações a isto dividem-se de forma muito nítida. Há quem veja isto como a direção natural da investigação — o estado do modelo como algo contínuo, em vez de snapshots. A metáfora que as pessoas usam é a diferença entre tirar uma fotografia do cérebro e observar o cérebro a funcionar.

Rafael Costa: E há quem faça exatamente o contra-argumento, com boa razão: treinar online, continuamente, abre problemas que a comunidade passou anos a fugir. Catastrofical forgetting — o modelo esquece o que sabia quando aprende coisas novas. Deriva de qualidade que ninguém consegue auditar. E um problema de segurança óbvio: se os pesos mudam com cada interação, o que impede que interações maliciosas empurrem o modelo para comportamentos indesejados?

Sofia Almeida: Sim, e há também a questão prática: atualização bayesiana online em escala de milhares de milhões de parâmetros é computacionalmente caríssimo. Os autores do artigo propõem o enquadramento; o quão longe isso está de funcionar em produção não está claro no que foi divulgado.

Rafael Costa: Mas o que me parece consenso na discussão, se é que há algum, é que a direção é importante mesmo que a implementação atual não seja a definitiva. A ideia de pesos gerados dinamicamente em função do contexto de interação desafina com tudo o que a indústria faz hoje — e às vezes é isso que vale a pena discutir.

Sofia Almeida: E há um terceiro ângulo nesta história da investigação em IA, mais aplicado. A OpenAI lançou o Astra for Law: GPT-6 Astra combinado com um índice de pesquisa legal com 230 milhões de URLs. No benchmark de pesquisa jurídica da Vals AI, alcança 54,0 por cento contra 38,7 por cento.

Rafael Costa: Vale notar contra quem — a comparação publicada é contra alternativas existentes na mesma avaliação, e a diferença de quinze pontos e meio é substancial num domínio como o direito, onde a precisão das fontes é crítica.

Sofia Almeida: As discussões aqui são de dois tipos. A primeira é técnica: um índice de pesquisa dedicado, com 230 milhões de URLs jurídicos, é uma vantagem enorme e um pouco injusta na comparação — parte do ganho não vem do modelo, vem dos dados. O que levanta a pergunta: quanto do resultado é GPT-6 e quanto é o índice? Sem uma separação clara, é difícil saber o que generaliza para outros domínios.

Rafael Costa: A segunda é a mais interessante a longo prazo: o Economist publicou esta semana que a IA já bate alguns dos melhores prognosticadores humanos. E aqui a discussão ficou acesa, porque muita gente no HN duvida da novidade — o argumento recorrente é que já sabíamos há tempos que modelos agregados fazem boas previsões em domínios bem definidos; a questão é se isso vale em domínios abertos, mal definidos, onde os prognosticadores humanos se supunha insubstituíveis.

Sofia Almeida: E há um contra-exemplo interessante nesta conversa que vem de outra direção: o Timothy Gowers, medallista Fields, explicou porque é que não assinou aquela carta contra provas matemáticas produzidas em massa por LLMs — apesar de concordar que há uma crise. A razão dele, tal como a contou, passa por discordar da forma do apelo mais do que do diagnóstico: assinar por assinar não ajuda a resolver o problema real.

Rafael Costa: Isso liga bem com a pergunta que atravessa tudo o que falámos até agora: se estas abordagens — modelos ternários, hiper-redes, agentes jurídicos, previsão automatizada — se generalizam, ou se são casos pontuais que parecem maiores do que são. Ninguém sabe ainda. E é essa incerteza que mantém a conversa viva.

Sofia Almeida: E essa incerteza leva-nos quase naturalmente para o próximo bloco, porque ferramentas eficientes só valem alguma coisa se as pessoas conseguirem usá-las juntas. E há uma startup do Y Combinator, a Skillsync — está no lote W26 — que atacou exatamente isso: o problema de as sessões de agentes de IA não falarem entre si.

Rafael Costa: Explico o problema, porque é real para quem trabalha com isto todos os dias. Quando usas o Claude Code, ou o Codex, ou o Cursor, crias uma sessão: a conversa, o raciocínio do agente, as chamadas a ferramentas, o histórico de edições. Tudo isso fica preso naquele produto. Se amanhã quiseres mudar de ferramenta — ou usar duas em paralelo no mesmo projeto — começas do zero.

Sofia Almeida: A Skillsync construiu uma engine chamada txcript, escrita em Rust, que porta essas sessões — o chat, o raciocínio, os tool-calls — entre agentes. Na prática, é uma camada de interoperabilidade entre assistentes de código.

Rafael Costa: A discussão em torno disto é fascinante porque toca numa dinâmica clássica. Por um lado, há quem veja aqui o padrão que já vimos noutros sítios: a primeira geração de uma categoria fecha-se, a segunda é aberta e interoperável, e o valor migra para a camada de portabilidade. Quem controla o histórico de trabalho ganha poder sobre quem controla o modelo.

Sofia Almeida: E por outro lado há o ceticismo estrutural: os fornecedores têm todo o interesse em manter as sessões presas — é o mais valioso que têm. Mesmo que a Skillsync consiga portar tecnicamente uma sessão do Cursor para o Claude Code, o que impede qualquer um deles de mudar o formato amanhã, ou de criar obstáculos contratuais? O valor de uma camada de interoperabilidade depende de os lados a quererem.

Rafael Costa: E há a questão de fundo que ninguém resolveu ainda: será que portar uma sessão preserva aquilo que importa? O raciocínio de um agente é muitas vezes implícito — está espalhado por decisões pequenas, por edições que ele experimentou e revertiu. Um formato comum consegue capturar isso, ou só captura o que é fácil de serializar? Isso é uma pergunta aberta e genuína.

Sofia Almeida: Completamente diferente, mas na mesma família de "ferramentas que mudam o trabalho": a Flet chegou à versão 1.0. Para quem não conhece, é um framework que permite construir aplicações cross-platform em Python puro, sem tocar em Kotlin, Swift ou JavaScript.

Rafael Costa: Os números: aplicações para seis plataformas, mais de 150 controlos, e por baixo usa o Flutter como motor de renderização — o que explica a maturidade visual. A parte mais curiosa é a web: corre via Pyodide, ou seja, Python compilado para WebAssembly no browser.

Sofia Almeida: As reações aqui dividem-se entre a alegria e a fisiologia. A alegria é óbvia: há um exército enorme de pessoas que sabem Python e não querem aprender quatro ecosistemas para fazer uma aplicação simples. A versão 1.0 importa porque significa estabilidade de API — o momento em que um framework pode ser usado em produção sem medo de tudo quebrar numa atualização.

Rafael Costa: E a fisiologia é a de sempre nestes casos: abstrações que funcionam nos casos comuns doem muito nos casos difíceis. As pessoas que usaram frameworks deste tipo contam experiências em que precisavam de um controlo fora dos 150, ou de um comportamento de plataforma específico, e aí a abstração vira um obstáculo. A questão não é se a Flet funciona — é até onde funciona.

Sofia Almeida: E há um exemplo prático que ilustra bem o lado do esforço individual aqui: o pawelwentpawel reconstruiu sozinho a flat.social, uma aplicação de reuniões 3D espaciais no browser, usando Three.js para o 3D, LiveKit para as chamadas e Rapier para a física. Bootstrapped a solo, com demo ao vivo.

Rafael Costa: E isto vale a pena sublinhar: há uns anos, uma app de reuniões espaciais exigia uma equipa. Hoje, uma pessoa com as bibliotecas certas consegue construir isto e pô-lo online. É a mesma tese dos modelos comprimidos — a barreira de entrada está a descer. O que falta ver, em ambos os casos, é a adoção real: quantas equipas de verdade trocam as ferramentas atuais por estas.

Sofia Almeida: E é aí que chegamos à parte menos confortável da história. Porque ferramentas novas trazem riscos novos, e esta semana houve dois episódios que mostram isso de forma muito concreta. O primeiro: a CrowdSec confirmou um vazamento do seu código-fonte em maio de 2026.

Rafael Costa: Recapitulando o que se sabe: a CrowdSec é conhecida pelo seu sistema de proteção contra ataques colaborativo. O código vazou — e a empresa confirmou o episódio publicamente. O vetor provável, segundo o que foi apurado, parece ser um compromisso da Tanstack, ou seja, o problema pode nem ter começado na CrowdSec, mas na cadeia de ferramentas que usa.

Sofia Almeida: E os pontos positivos que a própria empresa comunicou: não houve dados de clientes comprometidos, e os tokens foram rotacionados. Mas — e aqui está o que a discussão realçou — falta clareza sobre a cadeia completa do leak. Como é que o compromisso da Tanstack aconteceu? Havia mais afetados? A confirmação da empresa foi mais rápida do que a explicação técnica, e essa assimetria incomodou muita gente.

Rafael Costa: O comentário recorrente é: código fonte vazado não é o pior cenário — muitas destas ferramentas são open source de qualquer forma. O pior cenário seria se, além do código, tivesse havido acesso à infraestrutura, a segredos, a tokens válidos no momento do leak. A rotação de tokens sugere que isso foi considerado uma possibilidade real.

Sofia Almeida: O segundo episódio é a GitLab. A partir de 19 de outubro de 2026, os rate limits da GitLab.com passam a ser diferenciados por subscrição — anónimos ficam com 60 pedidos por hora.

Rafael Costa: E a leitura quase unânime da discussão é que o motivo real, mesmo que não seja o que está escrito no anúncio, é o LLM scraping. Modelos de linguagem a treinar sobre repositórios públicos geram tráfego colossal, e a resposta natural de quem opera a infraestrutura é cobrar ou bloquear.

Sofia Almeida: Aqui há uma tensão genuína que vale a pena articular. De um lado: quem opera o serviço tem de pagar os custos, e os crawlers de IA são um custo novo e enorme que não existia há dois anos. Rate limits por subscrição são uma resposta racional.

Rafael Costa: Do outro: rate limits por plano de pagamento atacam um problema que os crawlers criaram, mas punem sobretudo quem tem usos legítimos e de baixo orçamento — investigadores, ferramentas open source, pequenos scripts de automação. Os crawlers industriais arranjam formas de se autenticar ou de distribuir o tráfego. É o padrão clássico de uma política que pune os pequenos e contorna os grandes.

Sofia Almeida: E há uma pergunta em aberto que ninguém respondeu bem: qual é o futuro do acesso aberto a código público? Se a resposta institucional ao scraping de IA for fechar o acesso, o custo recai sobre tudo o que dependia desse acesso. Isso ainda não está resolvido — e as decisões desta semana são os primeiros sinais dessa direção.

Rafael Costa: E isso leva diretamente à pergunta mais desconfortável de todas: quando há tanto para proteger, onde é que se gasta o esforço? O essay do netmeister que saiu esta semana dá uma resposta provocadora: o verdadeiro gargalo de segurança não é encontrar vulnerabilidades — é fazer o patching.

Sofia Almeida: O argumento dele, tal como foi discutido, é este: gastamos quantias absurdas em ferramentas que descobrem vulnerabilidades — scanners, hunters, agora agentes de IA a procurar bugs — enquanto as vulnerabilidades conhecidas ficam sem patch durante meses. Encontrar o problema é o passo fácil e glamour; aplicar a correção é o passo chato, lento, e é aí que os ataques realmente acontecem.

Rafael Costa: A concordância com o diagnóstico é surpreendentemente larga — muita gente com experiência operacional confirma que a fila de patches pendentes é o pesadelo real. A discordância está no que fazer com isso. Alguns dizem que encontrar mais vulnerabilidades também pressiona a correção, porque cria urgência pública. Outros respondem que isso é exatamente o ciclo vicioso: mais finding, mais backlog, mais burnout de equipas de segurança.

Sofia Almeida: E o Cloudflare entrou nesta conversa com uma peça interessante: publicou uma security-audit-skill — uma skill para agentes de código que faz auditorias de segurança em várias fases, com findings verificados e legíveis por máquina.

Rafael Costa: A parte das "findings verificadas e legíveis por máquina" é a mais discutida. A ideia é que o output do agente não é um relatório em texto que um humano tem de triar — é algo estruturado, que pode ser validado e alimentado a processos posteriores. É uma tentativa de resolver o problema do ruído que os scanners clássicos produzem.

Sofia Almeida: Mas há quem veja a ironia: mais capacidade de auditoria não resolve o problema do netmeister. Se o gargalo é patching, um agente que encontra mais coisas pode até piorar o backlog. A skill do Cloudflare é útil se se ligar ao ciclo de remediação; se ficar no "aqui estão 500 novos achados", agrava o problema que o essay descreve. Isso ainda não está demonstrado.

Rafael Costa: E há mais um contributo nesta discussão sobre prioridades que vem da engenharia de software em geral: o detalhe do blog sobre o que chamaram "Tokenmaxxing". A tese, depois de uma desilusão com a abordagem de gastar tokens àaghan: faltam primitives para codebases que se auto-conduzem — e o trabalho mais valioso continua a ser boas ideias e boa arquitetura.

Sofia Almeida: O paralelismo com a segurança é muito direto: em ambos os casos, a resposta instintiva ao hype é "mais ferramenta, mais automação, mais volume", e em ambos os casos a resposta argumentada é "não, o que falta é pensamento de fundo — arquitetura, priorização, remediação". São conversas diferentes sobre o mesmo vício.

Rafael Costa: E há ainda uma peça metodológica que se encaixa aqui e gerou uma discussão própria: a tese de que classificação com LLMs é, no fundo, feature engineering. Em vez de pedir ao modelo uma decisão final, usas os julgamentos do LLM como features numa regressão logística.

Sofia Almeida: O que isso compra, segundo quem defende a abordagem: calibrabilidade — podes ajustar as probabilidades; thresholds claros — decides explicitamente onde corta; e interpretabilidade — consegues explicar porque é que uma decisão foi tomada, coisa que um output bruto de LLM não dá. Para quem trabalha em sistemas com consequências reais, isto não é detalhe, é requisito.

Rafael Costa: As discordâncias são as esperadas: há quem diga que modelos modernos já são suficientemente calibrados para muitas tarefas, e que a camada extra é complexidade desnecessária. A resposta dos defensores é que "suficientemente calibrado na média" não serve quando precisas de um threshold auditável. É uma discussão que ainda não tem veredicto — e o que falta é medir se estas práticas se espalham na indústria de verdade.

Sofia Almeida: E isto — o esforço posto no sítio certo — aplica-se perfeitamente ao próximo bloco, porque há uma série de projetos da comunidade que mostram pessoas a gastar o esforço de formas muito deliberadas. Começo pelo mais impressionante em termos de ambição: o Vinix, um sistema operativo moderno escrito em V.

Rafael Costa: Os números: corre com 100 megabytes de RAM, cabe num gigabyte de disco, tem suporte a M1 — e o detalhe que mais impressionou: corre binários do Alpine Linux nativamente, sem VM nem emulação.

Sofia Almeida: A reação majoritária é genuína admiração — escrever um OS é dos projetos mais difíceis que existem, e conseguir compatibilidade binária com Alpine significa que a base de software disponível salta instantaneamente para milhares de pacotes. É um atalho inteligente: em vez de escrever um ecosistema, herdar um.

Rafael Costa: E o ceticismo é o de sempre nestes casos: um OS que demonstra funcionalidade é diferente de um OS que é mantido a longo prazo. Quem mantém os drivers? Como acompanha o hardware novo? A equipa é pequena e a superfície é enorme. Mas como prova de conceito, é uma das coisas mais interessantes do ano.

Sofia Almeida: Mais abaixo na stack, mas igualmente prático: o Manticore Search adicionou auto-chunking embutido no INSERT, com cinco estratégias de divisão de documentos. E o número que se destaca: no teste com o próprio manual do produto, o recall@5 subiu de 55 para 83 por cento.

Rafael Costa: E isto importa porque ataca um problema real e banal de RAG: a forma como partes documentos antes de indexar determina completamente a qualidade da pesquisa, e quase toda a gente o faz mal e à mão. Automatizar o chunking no momento da escrita, com estratégias escolhidas automaticamente, remove um passo que é fonte constante de erros.

Sofia Almeida: As ressalvas na discussão: o benchmark citado é o manual do próprio Manticore — texto técnico, bem estruturado, ideal para chunking. Se os ganhos se mantêm em documentos desorganizados, PDFs confusos, tabelas — isso não está demonstrado. E há sempre quem diga que o chunking certo depende do caso de uso, e que automação total é ilusória. Ambas as posições têm argumento.

Rafael Costa: Na mesma onda de ferramentas pessoais, o Hister: uma pesquisa privada sobre as páginas que já visitaste e os teus próprios ficheiros. Tem extensão de browser e um servidor MCP, portanto liga-se a agentes de IA, e já está com 3,8 mil estrelas no GitHub.

Sofia Almeida: O que me parece a ideia mais certa da semana, e é isso que a discussão também diz: a memória mais valiosa que um modelo de linguagem pode ter sobre ti não é o teu histórico de chat — é aquilo que já leste e guardaste. Um índice local do teu próprio consumo de informação, privado por construção, é exatamente o tipo de primitive que faltava.

Rafael Costa: A dúvida óbvia: quem confia numa extensão de browser que indexa tudo o que vês? Mesmo que seja local, o code review necessário é substancial. O crescimento em estrelas sugere que muita gente aceita o trade-off — mas é um trade-off, e não há resposta técnica que o elimine completamente.

Sofia Almeida: E no capítulo "esforço bem colocado", o caso do Servo. O motor de browser fez um ano de desenvolvimento patrocinado, e os números do trabalho do Josh Bowman-Matthews são: oito maintainers nomeados, 1150 PRs revistos, e 92 por cento das issues de novatos corrigidas.

Rafael Costa: O número que a discussão mais comentou foi precisamente o último: 92 por cento das issues de novatos. Um projeto open source morre quando quem chega não consegue contribuir. Nomear maintainers e revisar mais de mil PRs é a infraestrutura invisível que faz um projeto sobreviver — e é raro ver-se esse trabalho celebrado com números concretos.

Sofia Almeida: E a contraparte, o aviso: o Bend 2, uma linguagem de programação com provas à la Lean — tem um mecanismo chamado LAWS.bend que bloqueia bugs de IA — velocidade de C e paralelismo em GPU. Tudo isso soa excelente. Mas o repositório foi esmagado num único commit, e isso gerou uma crítica séria à transparência.

Rafael Costa: E a crítica não é pedante. O histórico de um projeto é parte da sua credibilidade: mostra como as decisões foram tomadas, permite estudar a evolução, e — num contexto onde se fala em provar correção — apagar a história é exatamente o oposto da transparência que a proposta parece prometer. Squashar tudo num commit pode ter explicações razoáveis, mas, na ausência delas, a comunidade fica com a dúvida.

Sofia Almeida: E note-se o contraste com o Servo: um projeto que publica os seus números e processos em detalhe, e outro que comprime a sua história num commit. Mesmo tipo de esforço, filosofias opostas de abertura. Vale a pena acompanhar ambos no próximo ano.

Rafael Costa: E a seguir saímos do código para algo muito diferente: três retratos sociais que dizem muito sobre o nosso momento. O primeiro vem do Japão, que ultrapassou pela primeira vez os cem mil centenários: 107.677 pessoas com cem anos ou mais, das quais 88 por cento são mulheres.

Sofia Almeida: O número da longevidade em si é extraordinário — mas o que dominou a conversa foi o contra-ponto burocrático: um audit de 2010 encontrou 230.000 registos de pessoas com mais de cem anos sem paradeiro conhecido. Ou seja, os registos oficiais incluíam pessoas cujo paradeiro ninguém sabia — alguns já falecidos há décadas, mantidos vivos em papel por descuido ou por interesses familiares em pensões.

Rafael Costa: E é por isso que a discussão ligou este dado ao tema da gestão de dados que vimos no resto do episódio: um país pode ter as estatísticas mais avançadas do mundo em longevidade e, ao mesmo tempo, uma base de registos com problemas de limpeza fundamentais. A lição não é sobre o Japão — é sobre o que acontece a qualquer base de dados mantida durante décadas sem audit.

Sofia Almeida: O segundo retrato vem do New Yorker e é quase cómico: os Estados Unidos têm cerca de 90 por cento da capacidade mundial de self-storage — armazenamento de aluguer — mais de 40 mil milhões de dólares em receita anual, e mais locais do que as grandes cadeias de fast-food.

Rafael Costa: Quarenta mil milhões de dólares para guardar coisas que as pessoas não usam. A discussão leu isto de várias formas: como sintoma de consumismo, como sintoma de mobilidade — as pessoas mudam-se e não conseguem levar tudo — e como sintoma de habitação pequena. O que ninguém contestou é o retrato: um país inteiro a pagar renda por espaço para coisas paradas.

Sofia Almeida: E há um paralelo involuntário com o resto do episódio: falámos de modelos comprimidos, de sistemas operativos que cabem em 100 megabytes, de fazer mais com menos. E depois há 90 por cento da capacidade mundial de armazenamento dedicada a guardar o excedente de coisas que não se usam. São duas respostas opostas à abundância.

Rafael Costa: E o terceiro retrato é mais um convite do que um diagnóstico: o CCC — o Chaos Computer Club — vai realizar o 40C3, com o tema "Model Citizens", de 27 a 30 de dezembro de 2026 em Hamburgo. O call for participation está aberto.

Sofia Almeida: O tema é claro no seu propósito: "cidadãos modelo" — uma provocação sobre o que significa ser um bom cidadão num mundo de sistemas digitais que nos pontuam, nos classificam e nos modelam. Dado tudo o que discutimos hoje — agentes que nos substituem no código, modelos que nos batem em prognósticos, índices que nos vigilam —, o tema não podia ser mais oportuno.

Rafael Costa: E isso fecha bem o círculo do episódio. Começámos por modelos que fazem mais com menos pesos, passámos por ferramentas que portam trabalho entre sistemas, por vazamentos e rate limits que mostram os custos dessa expansão, por discussões sobre onde gastar o esforço — patching, arquitetura, feature engineering —, por projetos da comunidade a provar que o esforço bem colocado compensa, e terminámos em retratos sociais que nos lembram que a tecnologia é só uma parte da história.

Sofia Almeida: E o que fica de tudo isto? As questões em aberto: os modelos ternários escalam? As hyper-redes online superam o esquecimento catastrófico? O Astra generaliza para além do direito com o seu índice próprio? A interoperabilidade entre agentes sobrevive à resistência dos fornecedores? Encontra-se finalmente o equilíbrio entre encontrar vulnerabilidades e as corrigir?

Rafael Costa: Acompanhem o 40C3 — o call for participation está aberto — e digam-nos o que acham destes temas. Obrigado por nos ouvirem, aqui estava o Rafael Costa.

Sofia Almeida: E a Sofia Almeida. Até à próxima.