1026 | Quando todos (e todos os agentes) precisam de saber o que se está a construir

Sofia Almeida: Olá, bem-vindos ao briefing diário de lançamentos, o programa em que olhamos para o que apareceu nas últimas vinte e quatro horas e tentamos perceber o que há de verdadeiramente novo por baixo do ruído de lançamento. Eu sou a Sofia Almeida.

Rafael Costa: E eu sou o Rafael Costa. Sofia, hoje o fio condutor é claro: estamos numa fase em que todos os produtos mudam todos os dias — em parte porque agora são construídos com IA — e uma fornada de ferramentas lançou-se exatamente para resolver isso. Como é que a empresa inteira acompanha o que se está a construir? E depois, como é que os agentes, que já são colegas de trabalho, têm sítio para trabalhar?

Sofia Almeida: Exatamente. Vamos começar por aí, com dois produtos que atacam o mesmo problema em contextos diferentes: um ataca a questão "como é que o Suporte sabe o que mudou", o outro a questão "porque é que os meus números de receita não batem certo". O primeiro chama-se Specsight.

Rafael Costa: A história do fundador vale a pena contar. Chama-se Ola, engenheira, e diz que em todas as startups onde trabalhou era a pessoa a quem todos vinham fazer as mesmas três perguntas: como é que isto funciona, o que mudou, e isto é suposto acontecer? A resposta estava sempre no código, numa linguagem que a maioria da empresa não conseguia ler. Ela passou anos a ser a camada de tradução e nunca deixou de achar aquilo absurdo.

Sofia Almeida: E agora com IA o problema agravou-se: os produtos mudam todos os dias, ninguém consegue acompanhar o que está efetivamente a sair, mas continuam a precisar de conhecer o produto que estão a vender e a suportar. É isso que o Specsight tenta resolver.

Sofia Almeida: O que ele faz é acompanhar o produto diretamente do código-fonte, e gera uma série de coisas em linguagem de produto: um mapa do produto, que mostra que funcionalidades existem, como se comportam e como se ligam umas às outras; uma especificação com comportamentos documentados; um changelog do que mudou em cada versão; e respostas a perguntas — podes perguntar-lhe qualquer coisa sobre o produto. Também redige as notas de versão e envia um resumo semanal automático.

Rafael Costa: Nos exemplos do site vê-se bem o tipo de detalhe: "upload de ficheiros em bloco, agora até 10 de uma vez", "o limite de tamanho mudou para 20 MB", "o botão de guardar rascunho foi removido". Isso é exatamente o que um equipa de Suporte quer saber antes de os clientes perguntarem. E ao contrário das notas de versão, que só dizem o que é novo, mantém uma compreensão viva de todo o produto.

Sofia Almeida: Na prática, a Ola diz que o Vendas faz demos do produto como ele é hoje e não como era no mês passado, o Produto vê o que foi realmente construído em vez do que estava planeado, e o "deixa-me perguntar à engenharia" passa a ter resposta em segundos. Em termos de começar: ligas o GitHub ou GitLab, escolhes o repositório e o branch, e a maioria dos projetos recebe o primeiro mapa do produto dentro de uma hora.

Sofia Almeida: O acesso é só de leitura, o que é um bom sinal de que a ferramenta não precisa de escrever no vosso código. E há uma demo pública onde se pode ver o Specsight a acompanhar-se a si próprio.

Rafael Costa: Nota que tudo isto são as afirmações dela — trata-se como promessa do produto, não como resultados verificados. Mas uma pergunta concreta apareceu na discussão, e é boa: alguém do Suporte disse que metade dos tickets começa com "alguma coisa mudou?" e a resposta é sempre "deixa-me ver com a engenharia" — portanto o lado do Suporte é o que lhe interessa — e perguntou: o Specsight apanha mudanças que só existem em feature flags ou configuração, ou apenas o que está no repositório?

Sofia Almeida: E essa pergunta ficou sem resposta visível. É uma limitação potencialmente importante, porque muita coisa moderna só se ativa por flag ou por config, e se a ferramenta lê apenas o código, pode dizer que uma funcionalidade existe quando na verdade está desligada para os clientes. É uma das coisas a clarificar. Também vale a pergunta óbvia: como é preciso que as descrições geradas continuem precisas quando o produto muda — a Ola responde nas FAQ que há perguntas como "é sempre preciso?

Sofia Almeida: ", mas no material que temos não há garantia de precisão contínua. É o tipo de coisa que se valida a usar.

Rafael Costa: Do lado comercial, o que sabemos é que há 50% de desconto nos primeiros três meses para a comunidade — o anúncio foi cortado nesse ponto — e o pricing geral parece ser por organização. Não vou especular além disso.

Sofia Almeida: Agora, o segundo produto do mesmo tema — números que não batem certo — chama-se MRRaudit, e curiosamente foi construído pela própria equipa da ChartMogul, que anda desde 2014 obcecada com métricas de SaaS. Eles dizem que passaram anos a ajudar milhares de empresas a investigar estas diferenças à mão, através de chamadas e tickets de suporte, até que perceberam que deviam construir a ferramenta — primeiro para uso próprio, e depois perceberam que não havia razão para a guardar para si.

Rafael Costa: O problema é reconhecível para qualquer pessoa que trabalhe com receita recorrente: o Stripe diz uma coisa, o ChartMogul diz outra, e ninguém sabe qual é a certa. O MRRaudit compara os dois, cliente a cliente, e explica a causa de cada diferença, ligada às faturas e aos eventos de subscrição por trás.

Rafael Costa: No exemplo do site há um caso clássico: um cliente com faturação por uso — o Stripe classifica esse uso como receita não recorrente e não conta para MRR; o ChartMogul classifica-o como receita de subscrição e inclui. Nenhuma das duas está errada, depende de como o teu negócio trata o uso — e o MRRaudit deixa-te escolher.

Sofia Almeida: Os exemplos de causas são todos muito concretos. Faturas anuladas: se anulas uma fatura automática e substituis por uma fatura pontual, o Stripe continua a reportar 400 de MRR, mas o MRRaudit vê que não há fatura recorrente e põe o cliente a zero. Clientes em atraso: um cliente pode continuar a contar para o MRR três meses depois de deixar de pagar, se a subscrição nunca foi formalmente cancelada — o exemplo mostra 500 por mês a contar com a última cobrança feita em fevereiro.

Rafael Costa: E há mais: reembolsos tratados de forma diferente — o mesmo transação dá 1.200 ou 1.100 de MRR consoante os reembolsos são ignorados ou aplicados; descontos recorrentes, onde o MRR devia ser reportado líquido do desconto para refletir o que os clientes realmente pagam; e diferenças de estado — se o Stripe vê a subscrição ativa e o ChartMogul vê cancelada, o mesmo cliente conta como receita num sítio e como churn no outro, o que muda todas as métricas de retenção construídas por cima.

Sofia Almeida: O acesso é só de leitura e não precisas de conta ChartMogul — podes usar só com dados do Stripe. No tópico, alguém da comunidade disse algo que soa muito verdadeiro: a comparação cliente a cliente entre Stripe e ChartMogul é a vista que toda a gente acaba por reconstruir numa folha de cálculo no fim do mês. E colocaram a pergunta óbvia: como tratam um pagamento falhado que é recuperado dias depois? O cliente sai do MRR entretanto? Posso escolher essa regra?

Sofia Almeida: E outro: na equipa deles, as faturas de renovação ficavam em rascunho cerca de uma hora antes da cobrança, o que era fácil de ler como pagamento falhado — o MRRaudit mostra os rascunhos separadamente ou conta-os como renovações normais?

Rafael Costa: Essas perguntas ficam em aberto no material. Mas a promessa central — escolher como cada tipo de evento de faturação afeta o MRR — sugere que as regras são configuráveis, e isso é precisamente o que a comunidade pediu. Nota mais uma vez: tudo o que descrevemos vêm das afirmações dos criadores e de exemplos ilustrativos do site.

Sofia Almeida: A ligação entre estes dois casos é forte: em ambos, o problema não é que os números ou descrições estejam errados, é não saberes qual é a fonte de verdade e quem causou o desvio. E isso abre a próxima conversa — se toda a gente precisa de uma fonte de verdade partilhada, e os agentes de IA também já trabalham ao lado das pessoas, onde é que esse trabalho acontece?

Rafael Costa: E é aí que entra o AgentGrid.io, da equipa Anima, o co-fundador chama-se Avishay. A ideia dele: uma drive partilhada para humanos e agentes. A frase que eles usam é fixe — "Google Drive para humanos, Git para agentes". As pessoas editam documentos em simultâneo, tipo Google Docs; os agentes — Claude, ChatGPT, Codex, Cursor, e outros, via MCP, CLI e APIs — entram por uma interface de Markdown e Git.

Sofia Almeida: O que muda na prática: em vez de ficheiros duplicados e contexto espalhado, onde cada passagem de testemunho criava outra cópia e ninguém sabia qual era a atual, há um artefacto vivo — documentos, relatórios, slides, designs, e também aplicações HTML/React, que eles tratam como um novo tipo de documento. Exemplos de fluxo: o Claude cria um relatório, o ChatGPT melhora-o, o Grok Bot gera visuais, e um colega edita à mão — tudo no mesmo artefacto.

Sofia Almeida: Podes partilhar ou publicar sites e apps simplesmente pedindo ao teu agente. E há controlo: permissões granulares por agente e por pasta — ler, escrever, modificar, publicar — histórico de versões completo, e sabes quem mudou o quê, com restauração.

Rafael Costa: A Anima também tem um princípio de limites claros: os agentes autenticam-se como agentes, as permissões são explícitas, cada revisão tem histórico e cada aprovação tem um dono. Podes importar ficheiros, sites e designs do Figma para continuar a trabalhar com os teus agentes. No site há um site de marketing de exemplo onde se vê pessoas e agentes a colaborar no mesmo artefacto.

Sofia Almeida: A reação da comunidade foi de que falta mesmo isto — uma pessoa escreveu que o histórico de versões e os controlos de permissão são cruciais para equipas a sério, e que a colaboração multi-agente no mesmo artefacto resolve o problema "qual das versões da IA é que usámos afinal?". Mas atenção: são reações ao conceito, não relatos de uso prolongado. E o site indica SOC2 na navegação, o que sugere que a segurança é parte da proposta, mas não temos detalhes verificados.

Rafael Costa: Agora, se a questão é "controlo humano sobre ações de agentes", o segundo produto deste tema vai ao ponto mais sensível possível: dados sensíveis. Papermark Data Rooms 2.0, dos co-fundadores Iuliia e Marc — três anos de produto, dizem que mais de 80 mil utilizadores confiam-lhes negócios: fundadores, consultores de M&A, VCs, LPs e equipas de vendas.

Sofia Almeida: As queixas recorrentes que ouviram: montar uma sala de dados leva dias ou semanas, começa por uma chamada de vendas, a sala traz o logotipo do fornecedor e não o teu, e os teus agentes de IA não conseguem tocar em nada disto.

Sofia Almeida: A resposta deles: salas a funcionar em menos de 60 segundos, encriptação, certificações — SOC2 Tipo II, ISO 27001, HIPAA, GDPR e CCPA, centros de dados na UE, EUA e Emirados, e é self-hostable por serem open source — permissões granulares de ficheiros, controlos de acesso, módulo de perguntas e respostas integrado, e registos de auditoria com análise página a página, para saberes quem leu o quê.

Rafael Costa: E tudo white-label: a tua marca, o teu logótipo, o teu domínio. A frase de Marc é clara: uma sala de dados da Papermark parece a tua empresa, não a deles. Mas a parte de que a Iuliia mais gosta são os agentes — há API, CLI e um servidor MCP, para que o Claude, o Cursor ou o ChatGPT consigam montar uma sala quando lhes pedes. O exemplo dela: pedes "uma sala de M&A buy-side para o Project Atlas" e recebes de volta as pastas, as permissões e o link de partilha.

Sofia Almeida: E aqui a comunidade apanhou exatamente a questão de governança. Um comentário diz: pedir ao Claude "monta-me uma sala de M&A buy-side para o Project Atlas" e receber pastas e permissões de volta é uma boa demonstração de porque é que o MCP importa — mas quem tem autoridade para mudar permissões através do agente? Se alguém pede ao agente para dar acesso total a um consultor externo, passa logo ou espera por aprovação humana?

Rafael Costa: E essa pergunta não tem resposta no material disponível. É o debate que vai definir esta categoria: governança e controlo humano em tempo real sobre o que os agentes podem fazer com acessos sensíveis. O AgentGrid tem o mesmo tema em versão mais leve — permissões revogáveis por agente — mas numa sala de due diligence o risco é de outra ordem.

Sofia Almeida: Um utilizador real deixou um relato positivo: usam o produto no raising deles e recomendam. E houve um comentário simpático de quem gostava de poder usar mais o produto — o que nos diz algo sobre o público, são ferramentas para momentos raros mas críticos do ciclo de vida de uma empresa.

Rafael Costa: Vale ainda mencionar, no mesmo fio, um lançamento mais técnico: o git-flow-next, da equipa do Tower. É o sucessor do git-flow original, o modelo de branches que organiza funcionalidades, releases e hotfixes desde 2010, reconstruído do zero em Go, compatível com as configurações existentes, open source, e — detalhe relevante — endossado pelo próprio Vincent Driessen, criador do git-flow. A versão 2.

Rafael Costa: 1 acrescenta worktrees: começas uma funcionalidade no seu próprio diretório com --worktree, saltas entre worktrees com um comando, e podes torná-los o padrão, para que o Claude Code, o Codex ou qualquer outro agente que comece uma feature tenha o seu próprio diretório e possam trabalhar em paralelo sem se atrapalharem. Ao terminares, o worktree é limpo automaticamente.

Rafael Costa: A justificação deles: na era da IA, ter vários agentes lado a lado está a tornar-se a norma, e os worktrees são o que torna isso seguro.

Sofia Almeida: Isto liga bem com o que víamos: as equipas da Tower e da Anima estão a resolver o mesmo problema de coordenação humano-agente em camadas diferentes — uma no disco de trabalho partilhado, outra na estrutura de branches do repositório.

Rafael Costa: E isso conduz-nos diretamente à infraestrutura por baixo de tudo isto. Porque para os agentes trabalharem em browser, em código, em métricas — é preciso infraestrutura nova. Dois lançamentos a sério aqui. O primeiro é o Moli, da Lexmount, um motor de browser headless construído de raiz para agentes de IA.

Sofia Almeida: Os números que apresentam — e sublinho, são benchmarks deles, não verificados — dizem que o Moli arranca a frio cerca de cinco vezes mais rápido que o Chrome e usa cerca de um sétimo da memória. Porqui importa: se já construíste fluxos de agentes, sabes que levantar headless browsers pode tornar-se silenciosamente a parte mais cara.

Sofia Almeida: Como alguém escreveu na discussão, se estás a correr milhares de Chromes headless, os custos de recursos continuam a subir — é como as ventoinhas do portátil a disparar.

Rafael Costa: E o que me pareceu mais sério no discurso deles: o Donough, um dos makers, explica que deliberaram que leve e headless não devia sair à custa da segurança do browser. Trabalharam em restrições de mesma origem, sandbox de iframes, CSP, CORS, integridade de subrecursos, enforcement de MIME types, política de referrer. E a nota dele é boa: essas proteções importam tanto quando um agente de IA está a navegar como quando é uma pessoa.

Sofia Almeida: O modelo de negócio tem duas camadas. O Moli é o motor, open source, que podes correr localmente. O Lexmount é a plataforma cloud por cima: browsers geridos, com proxies, múltiplas sessões isoladas, e preços — nos números do lançamento, 100 horas de browser e 25 sessões concorrentes por 12 dólares/mês, com dois meses de Pro grátis para quem vier do Product Hunt. O SDK suporta Playwright, CDP, extensões, downloads e replay de sessões. Há um playground para testar antes de codificar.

Rafael Costa: E há uma peça mais ambiciosa: o Cloud Browser Agent, que executa tarefas com um protocolo próprio chamado CAE — Content, Action, Effect — que liga o conteúdo da página, as operações disponíveis e as mudanças observadas pelo browser, com atualizações incrementais para reutilizar contexto estável da página. A alegação é menos input redundante e menos gasto de tokens, e um traço de execução inspecionável.

Rafael Costa: O Wangli, primeiro engenheiro da plataforma cloud, também fala de uma direção interessante: um túnel de proxy local, em que o browser corre na cloud mas chega a um portal interno da empresa ou site atrás de VPN através de uma máquina na rede — com autorização explícita. E deixa a pergunta em aberto: que mais poderia um cliente local disponibilizar ao agente, com permissão do utilizador? Ficheiros? Câmara?

Sofia Almeida: As perguntas da comunidade mostram o que os developers realmente querem saber: um disseram que os agentes deles usam um browser real o dia todo e a parte lenta é sempre esperar por páginas e uploads, não o modelo — e perguntaram se o Moli mantém sessões autenticadas entre execuções ou se cada execução começa com perfil limpo. Outros perguntaram sobre conteúdo dinâmico, standards web modernos, e como conseguiram o cold start 5 vezes mais rápido. Nenhuma dessas tem resposta no material que temos.

Sofia Almeida: A compatibilidade com standards é uma pergunta justa para um motor construído de raiz — e a própria documentação deles diz para verificares as capacidades por motor antes de escolheres, oferecendo Chromium como alternativa para tarefas sensíveis à compatibilidade visual.

Rafael Costa: Agora o segundo pilar de infraestrutura: Llama Windows. Isto é o llama.cpp — a equipa do llama.cpp e a Hugging Face — a trazer modelos locais para o Windows 11 como uma app de bandeja do sistema.

Sofia Almeida: O que faz: recomendam modelos que cabem no teu PC, descarregas da Hugging Face num clique, e o app trata de correr o llama.cpp — escolhe quantização, tamanho de contexto, e por aí, automaticamente, e se sabes o que fazes, todas as definições do llama.cpp continuam disponíveis num ficheiro de texto simples. Alt+Space e falas com um modelo local de qualquer sítio.

Sofia Almeida: E o que é mais interessante estruturalmente: expõe um servidor local na porta 9931 que fala a API da OpenAI — portanto agentes de código, editores e scripts apontam todos para o mesmo sítio e partilham o mesmo servidor.

Rafael Costa: E a consequência prática que a comunidade notou: um comentário sublinha que ter um servidor local partilhado significa que cada app reutiliza a mesma cache de modelos em vez de cada uma embutir o seu próprio download de 20 GB. Os números do site são ilustrativos mas fortes: sem Llama, uma app de chat, um agente de código e a tua própria app somam 57 GB em disco; com Llama, 19 GB. Os modelos ficam na cache do Hugging Face, partilhada com o llama.cpp e outras ferramentas.

Sofia Almeida: E nada carregado quando está ocioso — os modelos carregam quando algo os pede e descarregam após cinco minutos. A app é pequena — 1 MB de download, 4 MB instalado, menor do que uma fotografia, como eles dizem. Sem terminal, sem direitos de administrador, sem inferência na cloud, sem chaves de API nem faturas de uso. Existe também versão para Mac, que é de onde veio primeiro, e versão de linha de comandos para Linux. Free e open source.

Rafael Costa: O comentário da comunidade sobre privacidade é representativo: correr localmente remove a dependência de APIs na cloud, sem limites de tokens, controlo total — bom para equipas com dados sensíveis ou para inferência offline. De novo, é a opinião de um comentador, mas o desenho do produto — tudo local, tudo na tua máquina — sustenta essa leitura.

Sofia Almeida: Em aberto aqui: as mesmas perguntas de sempre com modelos locais — o que cabe no teu hardware, e a qualidade face às APIs de topo. E a pergunta de compatibilidade de longo prazo: o próprio site admite que as recomendações variam por máquina — gemma para 16 GB, gpt-oss para 24, qwen para 32.

Rafael Costa: E agora ligamos ao último tema do dia — e é uma ponte natural: com esta infraestrutura, quem constrói passa a publicar cada vez mais depressa, e precisa de formas novas de medir e gerir isso. Dois casos: um sobre gestão de incidentes, outro sobre entender o que se tornou viral.

Sofia Almeida: O primeiro é o Openstatus Incident Management. O criador abriu o lançamento com a frase mais honesta do dia: "porque as status pages são uma mentira, e precisávamos de ir a montante". Outro comentário da comunidade repete a observação: a página fica verde enquanto o canal do Slack arde.

Rafael Costa: O que lançaram: gestão de incidentes para equipas pequenas, aberta e open source, ao lado dos monitores e da status page no mesmo workspace. Declaras um incidente a partir do Slack ou do dashboard — escreves /openstatus incident declare com título e severidade, aprovas o cartão, e o incidente existe, com o seu próprio canal. Cada incidente tem um canal com a severidade e o estado no tópico e o cartão do incidente afixado no topo.

Rafael Costa: Qualquer mensagem do Slack pode entrar na linha do tempo — reagis com um 📌 ou pelo menu. E há um detalhe prático: se o incidente ficar silencioso, há um lembrete — uma hora sem atualização para críticos, quatro para maiores, um dia para menores.

Sofia Almeida: E a peça inteligente: quando um monitor deteta a falha, declaras o incidente a partir da linha de downtime dele e a hora de início já vem preenchida — a duração conta desde o momento do impacto, não desde quando alguém se deu ao trabalho de declarar. Cada mudança de estado, nota e atualização pública fica com timestamp automático — eles dizem que o registo escreve-se a si próprio, e o postmortem e a trilha de auditoria são construídos a partir dele, não da memória.

Sofia Almeida: No fim, há um postmortem redigido. O exemplo no site é uma loja fictícia: um checkout com 503s na UE, severidade Major, resolvido em 55 minutos, com sete eventos na timeline do início até ao postmortem aprovado.

Rafael Costa: E a separação importante: interno e público ficam separados — a equipa trabalha com severidades, notas e um comandante, e os clientes leem um relatório de estado nas tuas palavras. Os dois ficam ligados, nunca misturados. O canal recebe já um primeiro relatório de estado redigido, com os componentes afetados e quando o problema começou, pronto a publicar num clique.

Sofia Almeida: A comunidade fez a pergunta certa: quando alguém declara a partir do Slack, a status page atualiza-se sozinha ou alguém ainda tem de aprovar o que os clientes veem? Isso fica sem resposta clara no material — mas o desenho, com um relatório redigido à espera de publicação, sugere que a intenção é haver um humano no circuito para o que é público. Preços: Starter grátis 14 dias, planos pagos a partir de 30 dólares/mês.

Sofia Almeida: Um comentário simpático de um cliente feliz disse que espera nunca ter de usar a nova funcionalidade — o melhor elogio possível a uma ferramenta de incidentes.

Rafael Costa: E o How It Spread é a mesma ideia aplicada a outra coisa completamente diferente: a viralidade. Uma biblioteca de mais de 1.650 casos — filmes, produtos, memes e campanhas — seguidos desde o primeiro post até ao pico. Eles chamam-lhe "o Mobbin para conteúdo viral", feito para estrategas e para os seus agentes.

Sofia Almeida: Os casos do topo mostram a variedade: o filme Obsession, 522 milhões de dólares de bilheteira com um orçamento de 750 mil a 1 milhão; KPop Demon Hunters com 4,6 mil milhões de impressões na web aberta; o vídeo do Doggface com o Ocean Spray, 15 mil milhões de impressões no TikTok; o chocolate de Dubai, 120 milhões de visualizações; Labubu, 2,05 mil milhões em receita. Para cada caso há uma linha temporal datada e com fontes.

Sofia Almeida: No caso Obsession: a estreia às 23h59 na secção Midnight Madness do TIFF, a 5 de setembro; a Variety a perfilar o realizador no mesmo dia, notando que a sua feature de 800 dólares no YouTube já tinha passado dois milhões de visualizações; dois dias depois o Deadline a reportar que a Focus Features estava em negociações exclusivas para comprar o filme por mais de 15 milhões. E há 16 eventos mais na timeline, com nota de que se juntando grátis se abrem todas.

Rafael Costa: Cada caso traz métricas deles próprias — alcance, contagio, amplitude, velocidade, longevidade — e gráficos de visualizações da Wikipédia e pesquisas da Google. É o mesmo princípio do Openstatus: registos estruturados e datados a substituir a memória e as narrativas. Ninguém lembra como as coisas ficaram grandes; aqui tens 19 eventos datados, 8 plataformas, 9 números com fonte, 23 fontes.

Rafael Costa: Em aberto: quanto deste registo pode ser automático sem ficar rígido — e no lançamento oferecem casos novos semanais por submissão, e Pro com 60% de desconto no primeiro ano com o código PATIENTZERO.

Sofia Almeida: E agora fechamos com o tema mais leve do dia, mas com um padrão que me agrada muito: ferramentas pequenas, criadas pelos próprios por necessidade, com licença única em vez de subscrição. Três casos. O primeiro é o Clips by Plastic — um criador chamado Kai Williams, músico com 30 mil ouvintes mensais no Spotify, que construiu a ferramenta enquanto promovia o seu álbum.

Rafael Costa: O problema dele: os anúncios de músicas funcionam melhor quando testas várias partes da música, mas cortar a mesma música quinze vezes num editor de vídeo levava uma noite inteira, por isso cortava duas e adivinhava. O Clips resolve isso: deitas lá a música terminada e as tuas imagens ou vídeos, ele deteta o tempo e todas as partes — versos, pré-refrão, refrão, bridge — e faz um vídeo vertical de letra por cada parte, cortado no ritmo, com as palavras sincronizadas palavra a palavra.

Rafael Costa: Escolhes um layout e um de 54 efeitos, e exportas todas as partes em todos os fundos de uma vez, com nomes prontos para o Ads Manager. Depois é a parte importante metodologicamente: corres tudo durante uma semana e pões o orçamento na parte que ganha — no exemplo do site, o vencedor foi o segundo verso, não o refrão, a 0,21 dólares por resultado contra 0,63 do refrão. Estranhos escolhem o vencedor, não o teu palpite.

Sofia Almeida: Funciona offline no Mac, por isso a música inédita nunca sai do computador — para um artista, isso é um argumento real. Livre para experimentar, com uma pequena marca do Clips nas exportações; 99 dólares uma vez para a remover, sem subscrição; há licença de estúdio/editora a 299 para trabalho de clientes. E há uma resposta afiada na FAQ para quem usa CapCut: guarda o CapCut para edições únicas, o Clips é para os quinze cortes quase idênticos que ninguém quer fazer à mão.

Rafael Costa: O segundo é o pawl — e este é encantador. Um timer de foco no menu bar do Mac que se inicia puxando uma pata de gato. Puxas a pata e o timer começa; arrastas para ajustar o tempo de foco, o tempo de pausa e o intervalo. Oito patas à escolha — tuxedo, laranja, calico, siamês — e temas. Dá um aviso calmo e configurável pouco antes de o tempo acabar, para a pausa não te apanhar de surpresa. 9,99 dólares uma vez, sem subscrição, metade do preço para estudantes, requer macOS 14.

Rafael Costa: A app direta tem cerca de 7 MB.

Sofia Almeida: E as testadoras levantaram as perguntas certas. Uma pessoa escreveu algo que muitos reconhecerão: corro timers no menu bar mas dispensa o chime e continuo a escrever na mesma — então o modo de pausa realmente te obriga a parar, ou só toca? E outra perguntou se o aviso prévio faz som ou só pisca. O maker respondeu no anúncio que o objetivo é tornar o começo pequeno e brincalhão e depois ficar fora do caminho — mas a honestidade da crítica fica: um timer que podes ignorar é só um relógio bonito.

Sofia Almeida: E houve quem confessasse — a propósito de quem não usa para nada — que só arrasta a pata quando tem saudades do gato.

Rafael Costa: E o terceiro: Badgey, de Marco Lüthi, que faz apps pequenas para iPhone sozinho. Transforma o teu iPhone num crachá de nome. Prendes o telefone a um cordão e viras-no ao contrário: o crachá roda para virar a cara para as pessoas à tua frente, e balança um pouco enquanto andas. E o detalhe engenhoso: no bolso do peito, metes o telefone de cabeça para baixo, primeiro pelo topo, e o crachá encolhe para uma tira, para o nome aparecer acima da orla.

Sofia Almeida: Como sabe que está no bolso? Usa a câmara frontal durante alguns segundos enquanto o telefone está ao contrário, e um pequeno modelo no próprio telefone decide — e as imagens nunca são guardadas. Podes ter vários crachás — trabalho, uma conferência, um meetup — com foto, nome, função e cor do cordão, e um link que se transforma num código QR no verso. Cinco designs: Classic, Office, Event, Minimal e Live, que se mexe. Grátis com um crachá, Pro é compra única. Requer iOS 26.

Rafael Costa: A comunidade gostou — um disse que é um ótimo conversador para conferências — mas as perguntas práticas estão certas: quanto dura a bateria com o ecrã ligado um dia inteiro de conferência? Impede o auto-lock do telefone? E o check do bolso corre todas as vezes que viras o telefone ao contrário? Ninguém respondeu no material que temos.

Rafael Costa: E um pedido recorrente e justo: a pessoa queria ver uma foto ou vídeo de como fica num cenário físico — porque sim, é uma app sobre um objeto físico, e os screenshots não chegam.

Sofia Almeida: E o padrão comum dos três: apps pequenas, feitas pelos criadores para resolverem os seus próprios problemas — o álbum do Kai, as saudades do gato, o crachá de conferência — com licença única em vez de subscrição. Num dia dominado por plataformas de agentes e infraestrutura, é um lembrete de que ainda se fazem ferramentas pequenas para si mesmos.

Sofia Almeida: E em aberto nos três: a bateria do Badgey, mais patas e cães no pawl — o próprio FAQ diz que cães são um dos pedidos mais frequentes — e onde o Clips vai a seguir.

Rafael Costa: Fechamos então o dia. O fio que atravessa tudo: quando o produto muda todos os dias — porque a IA acelerou a construção — o gargalo passou para saber o que foi construído, dar aos agentes um sítio para trabalhar com permissões e histórico, construir a infraestrutura de browser e modelos que os agentes partilham, e manter registos honestos e datados de tudo o que acontece — de incidentes a virais.

Rafael Costa: E ainda estamos longe de ter respostas para as perguntas difíceis: precisão contínua das descrições geradas, quem aprova o que os agentes podem mudar em acessos sensíveis, e quanta automação de registo é demais.

Sofia Almeida: Ficámos por aqui. Todas as afirmações que ouviste sobre capacidades e números vêm dos criadores e dos sites dos produtos — valem como promessas até alguém verificar. Obrigado por nos ouvires, e até amanhã para o próximo briefing.

Rafael Costa: Até já.