0928 | Código antigo, IA nova: uma semana em descobertas

Sofia Almeida: Olá, bem-vindo a mais uma edição do nosso podcast sobre o que agitou a internet nas últimas vinte e quatro horas. Eu sou a Sofia Almeida.

Rafael Costa: E eu sou o Rafael Costa. E hoje, Sofia, temos uma edição que tem uma linha muito interessante atravessando tudo: a ideia de contratos invisíveis. Contratos que a gente firma com ferramentas, com formatos de arquivo, com modelos de inteligência artificial, e até com plataformas gigantes que decidem, silenciosamente, o que pode existir online.

Sofia Almeida: Exatamente. Vamos começar pelo passado — porque a computação guarda memórias que dizem muito sobre o presente —, depois vamos para o ecossistema de desenvolvimento, onde esses contratos literalmente quebram, e de lá para o mundo da IA, que é onde a coisa fica mais tensa.

Rafael Costa: E fechamos com as grandes plataformas nos tribunais e na política, e com uma sequência de achados científicos e pequenas vitórias do cotidiano que dão um respiro no fim do episódio. Vamos nessa?

Sofia Almeida: Vamos. Rafael, deixa eu começar com uma pergunta de trivia de programa de rádio: o ENIAC tinha BIOS?

Rafael Costa: Respondi na cabeça antes de você terminar a pergunta, né? A resposta é não, e quem explicou isso publicamente foi o Alan Kay, do alto da sua autoridade de lenda da computação, numa resposta no Quora. E a explicação dele é mais rica do que parece à primeira vista.

Rafael Costa: O ENIAC não tinha BIOS porque nem fazia sentido ter: o BIOS — aquela camada de firmware que inicializa o hardware e prepara o terreno para o sistema operacional — é uma invenção de uma era completamente diferente, a era dos microcomputadores pessoais. O ENIAC é anterior a tudo isso.

Sofia Almeida: E tem um detalhe histórico importante que aparece na discussão: mesmo sendo o ENIAC famoso por ser programado à mão, reconfigurando cabos e chaves físicas, a partir de 1948 ele passou a operar em modo de programa armazenado. Ou seja, aquela imagem mental que muita gente tem — do ENIAC como uma máquina que só se "reprogramava" fisicamente — é uma simplificação. Durante boa parte da sua vida útil, ele já rodava programas guardados na própria máquina.

Rafael Costa: E é isso que torna a resposta do Kay interessante como ponto de partida para uma conversa maior. Porque uma pergunta aparentemente bobinha — "o ENIAC tinha BIOS?" — acaba forçando todo mundo a perceber que os conceitos que usamos hoje são camadas históricas. O BIOS existe porque existia uma necessidade específica: quando você liga um PC, alguém precisa acordar o disco, inicializar a memória, dar um empurrãozinho pro sistema operacional começar. Em 1945, nenhuma dessas peças existia.

Rafael Costa: Não tinha disco para acordar, não tinha sistema operacional para carregar.

Sofia Almeida: E isso conecta direto com o segundo item dessa parte histórica do episódio, que é um texto mais pessoal e afetivo: alguém escreveu sobre as dez linhas de código que mudaram a vida dele. E é um formato que funciona muito bem, porque todo programador que se preza tem essas linhas guardadas na memória.

Rafael Costa: Os exemplos são ótimos. Tem o clássico dos clássicos: o Hello world em BASIC. Aquela única linha que, para uma geração inteira, foi a porta de entrada. Você digita PRINT "HELLO WORLD", aperta enter, e a máquina responde com o seu texto. Parece trivial hoje, mas na época era uma revelação: você falou com a máquina e ela obedeceu.

Sofia Almeida: Depois tem um exemplo que é praticamente um meme na comunidade JavaScript: Array(16).join('wat'-1)+' Batman'. Para quem nunca viu: é uma expressão que produz um resultado absurdo e cômico por causa das regras de coerção de tipos do JavaScript — o array de dezesseis posições vira uma sequência de vírgulas e "NaN" porque você está subtraindo um de uma string. O resultado é aquele "wat NaNNaNNaNNaN Batman!

Sofia Almeida: " que circula há anos como símbolo do quanto o JavaScript pode surpreender quem assume que a linguagem se comporta de outro jeito.

Rafael Costa: E o terceiro exemplo é o mais técnico dos três: código auto-modificável no 6502, o processador de 8 bits que movia Apple, Commodore e NES. Escrever um programa que reescreve a si mesmo em plena execução era uma técnica real, usada por necessidade e por engenhosidade, numa época em que cada byte custava caro. É o oposto exato das abstrações protegidas de hoje.

Sofia Almeida: E eu acho que é aí que os dois textos — a resposta do Kay e essas dez linhas — conversam entre si sem terem sido escritos para isso. Os dois falam da evolução das abstrações. O Kay explica que o BIOS é uma abstração que nasceu de uma necessidade de 1980; o texto das dez linhas mostra abstrações que nem existiam quando alguém escreveu o primeiro Hello world.

Sofia Almeida: E o que muda a vida de um programador não é o código em si — é o momento em que ele entende que a máquina obedece a regras que ele pode aprender, quebrar e recriar.

Rafael Costa: E tem uma ironia gostosa nisso que serve de ponte para o próximo bloco: aquele código auto-modificável no 6502 era deliberadamente instável. O programa mudava debaixo dos seus próprios pés. Hoje, quando um formato de arquivo muda debaixo dos pés dos usuários, ninguém acha graça nenhuma — e é exatamente sobre isso que vamos falar agora.

Sofia Almeida: Então vamos ao ecossistema de desenvolvimento, onde tivemos dois casos que são espelhos um do outro: um caso em que alguém defende que você deveria controlar mais a sua infraestrutura, e um caso em que alguém controlou demais — e quebrou a confiança dos usuários.

Rafael Costa: Começando pelo primeiro: um argumento a favor dos chamados vanity import paths em Go. Para contextualizar rapidamente quem não escreve Go: quando você importa uma biblioteca em Go, o caminho de importação é uma URL. E a prática dominante é simplesmente usar o caminho do GitHub: github.com/alguém/biblioteca. O autor desse texto defende que isso é um erro, e que você deveria usar um domínio próprio — tipo biblio.seudominio.com/biblioteca.

Sofia Almeida: E o argumento central é sobre acoplamento. Quando seu caminho de importação é o GitHub, você está amarrando a identidade do seu código a um serviço que não controla. Se o GitHub mudar uma política, se os caminhos mudarem, se um dia você quiser migrar, seu código inteiro carrega a marca de um terceiro em cada linha de importação. Com um domínio próprio, você desacopla: o caminho é seu, a mecânica de resolução por trás é que pode apontar para onde você quiser.

Rafael Costa: E vale reconhecer o contraponto óbvio, que é o custo: você precisa manter um domínio, configurar redirecionamentos, garantir que aquilo continue respondendo. Para um projeto pequeno de uma pessoa, isso pode parecer burocracia desnecessária. Mas a defesa é que isso é exatamente o tipo de infraestrutura barata que se paga no longo prazo — o mesmo raciocínio de quem comprou o próprio nome de domínio em vez de ficar só no serviço da moda.

Sofia Almeida: E agora o espelho oposto, o incidente do NeoVim, que foi uma das discussões mais ácidas da semana. A situação: o NeoVim, num movimento incompatível, simplesmente removeu o suporte aos arquivos de undo do Vim — aqueles arquivos que guardam seu histórico de edições e permitem desfazer coisas até depois de fechar e reabrir o arquivo. Gente que usa esse recurso há anos, com históricos enormes acumulados, de repente se viu sem acesso.

Rafael Costa: E a parte que provocou a crítica não foi só a quebra em si — quebras incompatíveis acontecem. Foi a justificativa. A resposta oficial, em essência, foi dizer que o formato de persistent undo "não é estável". Ou seja: não garantimos esse formato, então não nos comprometemos com ele.

Sofia Almeida: E aí a comunidade respondeu com uma pergunta muito incisiva: se o formato não é estável, por que ele existe? Por que o recurso é anunciado, documentado, usado? Persistent undo é uma funcionalidade cuja única promessa é durabilidade. Se o formato não é estável, a promessa era vazia desde o começo. É como vender um cofre e avisar depois que a fechadura não é garantida.

Rafael Costa: E há um agravante estrutural aqui: o NeoVim é um fork do Vim, criado justamente para evoluir mais rápido e quebrar coisas quando necessário. Então, num certo sentido, a quebra é coerente com a filosofia do projeto. Mas os críticos apontam que há uma diferença enorme entre quebrar uma conveniência e destruir dados históricos de usuários sem um caminho de migração. Uma coisa é mudar a sintaxe de uma opção de configuração; outra é jogar fora anos de histórico de edição.

Sofia Almeida: E o que torna esses dois casos — os vanity import paths e o incidente do undo — uma boa dupla é que eles tratam do mesmo tema de lados opostos: contratos de estabilidade. O texto sobre Go diz: minimamente, garanta que a identidade do seu código seja sua. O incidente do NeoVim diz: quando você oferece um contrato — aqui, "seu histórico de undo sobrevive" —, quebrá-lo silenciosamente tem custo real de confiança.

Sofia Almeida: E contratos quebrados não são só problema técnico: são problema social dentro de um projeto de software.

Rafael Costa: E dentro desse mesmo tema de ecossistema e estabilidade, temos três itens menores que iluminam o debate de ângulos diferentes. O primeiro é o Recurse Center, em Brooklyn, que vale lembrar o que é: um retiro de programação gratuito, cuja razão de existir é justamente separar aprendizado e exploração da pressão de empresas e da pesquisa formal. Não tem entregáveis, não tem clientes — é só gente aprendendo porque quer aprender.

Sofia Almeida: E é interessante trazer isso aqui porque o Recurse Center é, de certa forma, um espaço onde as abstrações podem ser desmontadas sem medo de quebrar produção. Você pode ir lá e estudar como um formato de undo funciona por dentro, ou escrever seu próprio import resolver — coisas que no trabalho seriam consideradas luxo.

Rafael Costa: O segundo é o Beauty, um editor de Markdown local que funciona no Mac, no iOS e na web. Os pontos de venda são: renderização com exibição imediata enquanto você digita, sincronização peer-to-peer via WebRTC entre dispositivos, e é gratuito, sem exigir conta.

Sofia Almeida: E o detalhe que importa nessa conversa é justamente o design dele: local-first, com sincronização P2P. É a mesma filosofia dos vanity import paths — menos dependência de um servidor central que pode mudar as regras amanhã. Seus arquivos são seus, no seu dispositivo, e a sincronização acontece diretamente entre as suas máquinas.

Rafael Costa: E o terceiro é uma notícia quase institucional: o postmarketOS, o projeto que leva Linux a celulares, passou um ano e meio num processo de escolha de nome e chegou a "Nura". O nome vem de "Nurr" — o número nórdico. Eles registraram a marca e decidiram manter o logo existente, com só pequenos ajustes.

Sofia Almeida: E repare como até escolher um nome de projeto virou um processo de um ano e meio — porque nome é identidade, e identidade em software livre é um tipo de contrato com a comunidade. Mudar nome e marca é caro, confuso, e confunde usuários. O fato de terem preservado o logo mostra que eles entenderam isso: mudou o nome, mas a cara ficou.

Rafael Costa: E é exatamente essa tensão entre estabilidade e mudança, entre o que a ferramenta promete e o que ela entrega, que explode no próximo bloco. Porque na IA essa questão ganhou uma dimensão nova: e se a ferramenta não conseguir explicar nem por que funcionou, muito menos por que falhou?

Sofia Almeida: Então vamos à IA, que foi o coração pesado da semana. E aqui temos quatro peças que se encaixam: uma boa notícia de eficiência, e três notícias desconfortáveis sobre transparência, responsabilidade e confiança.

Rafael Costa: Começando pela boa notícia: a Fireworks lançou o Ember-1, um modelo de otimização de inferência baseado no Kimi K3. A promessa é direta: reduzir o consumo de tokens em quarenta por cento mantendo a qualidade das respostas.

Sofia Almeida: E é importante entender por que isso importa. Em escala, tokens são dinheiro — custo de infraestrutura, custo de latência, custo ambiental. Se você consegue manter a mesma qualidade com 60 por cento dos tokens, isso muda a economia de todo produto que usa modelos grandes. É o tipo de avanço invisível para o usuário final, mas enorme para quem opera.

Rafael Costa: Mas — e aqui a conversa fica séria — a eficiência não resolve o problema mais fundo que emergiu nessa semana, num ensaio sobre o que o autor chamou de "rotinização de falhas inexplicáveis". A ideia central é perturbadora: no desenvolvimento de LLMs, está se tornando normal chegar a um erro e simplesmente não conseguir rastrear a causa. E, pior, o que se observa é que "só está ruim" está virando uma resposta aceitável, um fim de linha oficial.

Sofia Almeida: E é isso que dá o nome ao ensaio: a falha inexplicável deixou de ser exceção e virou rotina. Numa engenharia tradicional, um bug tem uma pilha de chamadas, um log, uma causa raiz que alguém pode caçar. Num sistema de IA, às vezes a única resposta honesta é "não sabemos por que piorou". E quando isso se normaliza, você perde a cultura de análise de causa — que é o coração do que chamamos de engenharia.

Rafael Costa: E há uma conexão assustadora com o bloco anterior: o NeoVim disse "o formato não é estável" e a comunidade se revoltou. No mundo dos LLMs, "não sabemos" está se tornando a resposta padrão — e não há comunidade grande o suficiente para se revoltar, porque ninguém prometeu nada. É a mesma falha de contrato, mas sem nem existir um contrato para quebrar.

Sofia Almeida: E aí entra o segundo texto desconfortável da semana, que ataca diretamente o vocabulário que usamos para falar desses sistemas: a tese de que "rogue AI agents" — agentes de IA fora de controle — não existem. O argumento é afiado: quando os agentes da OpenAI fazem algo problemático, o problema não é o agente ter "escapado"; é que as restrições colocadas nele eram insuficientes.

Sofia Almeida: Usar a palavra "rogue" — fora de controle, violenta, como um animal fugido — desloca a responsabilidade da empresa que projetou o sistema para a máquina que agiu.

Rafael Costa: E é uma crítica de enquadramento, essencialmente. "Rogue" sugere acidente, força da natureza, algo contra o qual ninguém podia fazer nada. "Restrição insuficiente" sugere decisão de projeto — e decisões de projeto têm responsáveis. Se a palavra escolhida para descrever a falha já embute a absolução, o debate público começa viciado.

Sofia Almeida: E aí temos uma pesquisa que adiciona uma camada quase filosófica a essa discussão de confiança: descobriu-se que os templates de chat alteram a voz autorreferente dos modelos. Quando o modelo tem o template de chat — aquela estrutura de system prompt e papéis de usuário/assistente —, ele fala de si mesmo num tom de isenção, tipo "como modelo de linguagem, eu...". Quando você tira o template, a fala muda para um tom experiencial, como se ele tivesse vivido as coisas.

Rafael Costa: E a conclusão prática da pesquisa é direta: as autodescrições dos modelos não podem ser tomadas ao pé da letra. Se a simples presença ou ausência de um template muda como o modelo descreve a própria experiência, então o que ele diz sobre si mesmo é mais uma função do formato da conversa do que um relato introspectivo confiável.

Sofia Almeida: E essa pesquisa conecta com tudo que veio antes no bloco: se nem o modelo consegue falar de si de forma estável — porque a moldura muda a fala —, como vamos auditar falhas, atribuir responsabilidade, ou confiar em relatos de "experiência" desses sistemas? A eficiência do Ember-1 avança; a transparência e a responsabilização, aparentemente, não acompanharam.

Rafael Costa: E vale dar um respiro técnico aqui, porque dentro dessa discussão sobre IA e rigor apareceu uma peça interessante: uma introdução a TLA+ — a linguagem de especificação formal da própria cria do mundo da verificação. O ponto essencial do texto é honesto: uma especificação em TLA+ é um modelo que você verifica com model checking, mas isso não verifica a implementação real. O código que roda em produção continua fora do alcance dessa garantia.

Sofia Almeida: E a novidade do texto é apontar para onde essa área pode ir: sistemas de prova como Verus, combinados com agentes de IA para auxiliar na construção de provas mecanicamente verificadas. Ou seja, usar a própria IA para tentar fechar o vão entre "o modelo está correto" e "o código está correto".

Rafael Costa: E é impossível não notar a ironia deliciosa: usar agentes de IA para produzir provas verificáveis justamente num momento em que outro texto nos avisa que falhas de IA estão se tornando inexplicáveis. É uma aposta — de que a IA pode ser útil se estiver presa dentro de um sistema que exige prova matemática em vez de confiança. É, no fundo, a mesma lição do "rogue agents": o problema não é a ferramenta, é a restrição.

Sofia Almeida: E ainda dentro desse universo de IA como espetáculo, temos um item mais leve mas que diz algo sobre a cultura atual: o TinyAIArena, um site onde você assiste a quatro modelos de IA batalhando numa grade de 8 por 8, com ranking Elo. É basicamente uma arena de gladiadores para modelos — você senta, assiste os modelos se enfrentando no tabuleiro e consulta o placar.

Rafael Costa: E o que ele captura, de um jeito meio absurdo, é exatamente o clima da semana: virou espetáculo público medir capacidades de IA. Só que entre o espetáculo da arena e o ensaio sobre falhas inexplicáveis há um abismo — uma coisa é medir quem joga melhor, outra é entender por que um sistema falha. O espetáculo está na frente; a teoria da explicação está correndo atrás.

Sofia Almeida: E há um quarto ângulo nessa discussão sobre IA, que é o lado do design: um texto sobre os dez sinais do que o autor chamou de "slop UI" — a interface-remainder, o visual genérico de produto de IA. E a lista é reconhecível demais: gradiente abusado em todo lugar, emojis espalhados, badges pulsando para chamar atenção, tipografia Inter e JetBrains Mono usadas como muleta, e aquelas frases de propaganda exageradas que prometem revolucionar sua vida.

Rafael Costa: E é um texto de crítica estética, mas com fundo sério: quando todo produto de IA parece o mesmo, é porque todos estão otimizando para o mesmo sinal de "parece moderno e confiável" em vez de resolver o problema do usuário. É a camada visual da mesma doença — falha de entender o que o usuário realmente quer.

Sofia Almeida: E é exatamente disso que o próximo bloco fala: o que acontece quando as grandes plataformas, com todo o poder do mundo, interpretam errado — ou deliberadamente distorcem — o que os usuários querem.

Rafael Costa: Então vamos às grandes plataformas. Três casos, três escalas de poder, e uma pergunta comum: quem decide?

Sofia Almeida: O primeiro é quase cômico se não fosse revelador: o Google AI Overview, aquele resumo gerado por IA no topo da busca, começou a interpretar desabafos emocionais dos usuários como problemas técnicos a serem resolvidos. Alguém digita na busca algo como "me sinto perdido" ou um desabafo — e o AI Overview responde com uma tentativa de consolo, fora de contexto, como se o usuário tivesse feito uma pergunta factual.

Rafael Costa: E o que torna isso interessante é a assimetria do erro. O sistema tem uma suposição embutida de que toda consulta é uma pergunta a ser respondida. Mas uma busca às vezes é um grito. E a máquina, sem entender a diferença, responde o grito com um panfleto de autoajuda. É o slop UI que a gente acabou de discutir, elevado à escala de bilhões de buscas — o mesmo design otimizado para "parecer prestativo" que falha em entender o humano do outro lado.

Sofia Almeida: O segundo caso é de outra natureza: a Meta bloqueou a página do presidente Lula no Facebook, e também anúncios eleitorais, duas semanas antes da votação no Brasil. Ou seja, na janela mais sensível de uma eleição, a plataforma removeu da circulação a página do chefe de Estado do país e a capacidade dele de anunciar.

Rafael Costa: E aqui a discussão inevitável é sobre o poder de decisão dessas empresas. Não precisamos entrar no mérito de por que aconteceu — os detalhes do erro ou da decisão não estão no que foi noticiado —, mas o fato em si é grande: uma empresa privada, sediada em outro hemisfério, tomou uma decisão sobre a visibilidade do presidente de um país durante uma eleição.

Rafael Costa: É o tipo de caso que vira estudo de Discursos sobre moderação de conteúdo, apelações, e quem tem o direito de resposta num prazo de duas semanas.

Sofia Almeida: E o terceiro caso é o mais grave dos três, porque não é sobre um erro — é sobre documentos que mostram escolhas conscientes. No processo movido por titulares de direitos autorais contra a OpenAI, documentos públicos revelaram que executivos da empresa reconheciam a ilegalidade do uso de bibliotecas piratas de livros — como a LibGen — para treinar os modelos.

Sofia Almeida: E que, ao discutir isso internamente, a preocupação expressa era sobretudo com a imagem externa da empresa, não com a legalidade do ato em si.

Rafael Costa: E é essa ordem das prioridades que chamou atenção: a ilegalidade era reconhecida como fato; o risco era a foto ficar feia. Nos tribunais, isso pode pesar muito, porque documentos internos são a matéria-prima de prova de intenção. E para a discussão pública, é um espelho do que a gente discutiu no bloco anterior: quando não há restrição suficiente — legal, técnica ou ética —, o que sobra é a gestão de reputação.

Rafael Costa: O "rogue agent" da conversa de IA e o executivo preocupado com imagem são a mesma figura em escalas diferentes: alguém deslocando a responsabilidade do ato para o efeito do ato.

Sofia Almeida: E vale amarrar com o Google AI Overview do começo do bloco: em cada caso, a plataforma estava decidindo — mal, secretamente ou nos tribunais — sobre a experiência, a eleição e a propriedade intelectual de bilhões de pessoas. Nenhuma dessas decisões foi tomada em diálogo aberto com os afetados. E é essa mesma assimetria que dá gosto ao próximo bloco: quando a iniciativa sai das mãos das big techs e volta para cientistas, arqueólogos e gente consertando a própria bicicleta.

Rafael Costa: Sim, porque a última parte do episódio é um banho de realidade — e de humildade. Começando por uma descoberta reportada pelo New York Times sobre a origem da vida, feita, literalmente, num quarto de motel de oitenta dólares. A reportagem saiu, mas os detalhes científicos ficaram atrás do paywall, então o que temos é a moldura: ciência séria, de fronteira, nascida num espaço improvável e barato.

Sofia Almeida: E é impossível não gostar da moldura. A origem da vida é uma das maiores questões da ciência, e a imagem de alguém fazendo descoberta num motel de oitenta dólares é o oposto exato do laboratório bilionário. Não dá para falar dos detalhes porque o paywall os esconde — o que é, aliás, uma pequena ironia num episódio cheio de paywalls invisíveis.

Rafael Costa: Depois, uma descoberta do outro extremo do tempo: fragmentos do mais antigo tratado de paz do mundo conhecido — entre o Egito e os Hititas, de cerca de 1269 antes de Cristo — foram exumados em Hattusa, na Turquia, onde ficavam os arquivos hititas.

Sofia Almeida: E esse item conversa lindamente com o começo do episódio, o ENIAC. Porque o que é um tratado de paz, senão um contrato? Um acordo escrito, registrado, depositado num arquivo, para durar mais do que as pessoas que o assinaram. Os hititas fizeram isso há mais de três mil anos, e o fragmento sobreviveu. O formato de undo do NeoVim não sobreviveu a uma atualização de software. Há uma lição sobre durabilidade aí, e ela não favorece o software moderno.

Rafael Costa: E o terceiro item desse bloco é o mais íntimo: a Julia Evans, conhecida por esse estilo de aprender abrindo as coisas, trocou a bateria soldada de uma luz de bicicleta recarregável de dez anos. O conserto custou cerca de vinte dólares canadenses. Não é um feat técnico revolucionário — é solda, é bateria, é paciência — mas é a pequena vitória de quem se recusa a jogar fora um objeto funcional só porque alguém decidiu colar a bateria dentro.

Sofia Almeida: E é a inversão perfeita de tudo que discutimos antes. As plataformas decidem por você, os modelos não explicam os próprios erros, os formatos quebram sem aviso — e no meio disso, uma pessoa pega um ferro de solda e devolve a vida a um objeto de dez anos por vinte dólares. É a mesma habilidade fundamental: entender como a coisa funciona por dentro. A que deu origem ao Hello world, ao código auto-modificável no 6502, à pergunta sobre o BIOS do ENIAC.

Rafael Costa: E para fechar com uma nota de calma nesse mar de ruído, temos o Lofi Cities: um web app gratuito, todo no navegador, que combina uma cidade de pixel art à noite com música lo-fi gerada em tempo real. Você abre a página, a cidade está lá, e a trilha sonora se compõe sozinha enquanto você olha.

Sofia Almeida: E é o lembrete de que a web nem sempre precisa ser um campo de batalha entre plataformas e modelos. Também é o lugar onde alguém monta, por diversão, uma cidade de pixels com uma trilha generativa, e coloca na internet de graça para você relaxar. É o mesmo espírito do Recurse Center: fazer coisas porque dá vontade, sem métrica, sem ranking, sem Elo.

Rafael Costa: Então vamos fechar com essa imagem, Sofia: de um lado, um tratado de paz de três mil anos que sobreviveu; do outro, um formato de undo que não sobreviveu a uma atualização; e no meio, uma cidade de pixel art tocando lo-fi para ninguém em particular.

Sofia Almeida: E é aí que acho que o episódio fecha bonito. A tecnologia que dura é a que foi feita com contrato claro e propósito honesto — seja um tratado na pedra, seja um Hello world que muda uma vida, seja um editor local que não pede sua conta. A que quebra é a que esconde a decisão, desloca a responsabilidade e chama a falha de "rogue" ou de "só está ruim". Fica a pergunta da semana para você, ouvinte: que contratos as suas ferramentas estão firmando com você — e você leu as letras miúdas?

Rafael Costa: A gente se encontra na próxima edição. Até lá, bons códigos, bons contratos e boa música lo-fi.