Meu objetivo é ajudar as pessoas, mas está dificil ajudar sem ter nenhuma verba para ajudar a pagar os anuncios (que é a engrenagem do projeto). Tenho varios programas que ajudam, como um ajustador de currículo online e mais coisas. Alguém tem ideias para contribuir?
https://opiniaosul.com

Em 2020, publiquei um texto dizendo que CSS4 nunca existiria como a próxima versão única do CSS. Recentemente, um leitor encontrou aquele artigo e disse que eu não estava sendo totalmente sincero.

Ele tocou no ponto certo.

Não porque o W3C tenha lançado um pacote chamado CSS4. Isso não aconteceu. O problema é que responder apenas "CSS4 não existe" deixa de fora quase tudo o que aconteceu com a linguagem nos últimos seis anos.

A resposta curta e precisa, em setembro de 2026, é esta:

CSS4 e CSS5 não existem como versões oficiais únicas da linguagem. Depois do CSS Level 3, os módulos passaram a evoluir de maneira independente. Por isso existem Selectors Level 4, CSS Color Level 4 e CSS Cascade Level 5 sem existir uma versão global chamada CSS4 ou CSS5.

Só que a discussão do nome ficou pequena. O CSS atual já consegue reagir ao tamanho de um componente, ao estado dos elementos dentro dele, à posição do scroll e à localização de uma âncora. Ele também ganhou estados nativos de interface, trajetórias de movimento, formas declarativas e espaços de cor perceptuais.

A pergunta útil deixou de ser "qual é a versão do CSS?". Agora ela é: como saber o que já pode entrar em produção e o que ainda precisa de fallback?

Snapshot, Baseline e Interop respondem a perguntas diferentes

Tratar esses três projetos como sinônimos cria uma falsa sensação de segurança.

O CSS Snapshot 2025 é explícito: módulos independentes podem chegar ao Level 4 ou além, mas a linguagem inteira não possui mais esses níveis. O mesmo documento também avisa que a inclusão de um módulo considera estabilidade da especificação, não sua taxa de adoção nos browsers.

Baseline e Interop completam a análise, mas a decisão final ainda depende da sua audiência e do papel daquele recurso na interface.

Três provas de que o problema mudou

1. Um componente pode responder ao próprio espaço e ao estado interno

Media queries observam o viewport. Container queries permitem que a unidade responda ao espaço que realmente recebeu no layout.

<article class="probe">  <label>    <input id="advanced" type="checkbox">    Exibir telemetria avançada  </label>  <div class="probe__layout">    <section>Métricas</section>    <aside>Detalhes</aside>  </div></article>

.probe {  container: probe / inline-size;}.probe__layout {  display: grid;  gap: 1rem;}@container probe (min-width: 36rem) {  .probe__layout {    grid-template-columns: 2fr 1fr;  }}.probe:has(#advanced:checked) {  border-color: oklch(72% 0.2 250);}

O layout responde ao contêiner, não à tela inteira. O elemento pai reage ao checkbox com :has(), sem listener de clique e sem uma classe sincronizada por JavaScript.

Isso não transforma CSS em linguagem de regra de negócio. Significa apenas que decisões de apresentação podem permanecer na camada que já conhece o layout e a estrutura.

2. Um popover pode abrir e se posicionar sem calcular coordenadas

O HTML representa a abertura. O CSS relaciona o painel à sua âncora.

<button class="beacon" popovertarget="telemetry">  Abrir telemetria</button><aside id="telemetry" popover>  Dados do módulo selecionado</aside>

.beacon {  anchor-name: --beacon;}@supports (position-anchor: --beacon) {  #telemetry:popover-open {    position-anchor: --beacon;    top: anchor(bottom);    left: anchor(center);    translate: -50% 0.5rem;  }}

Sem anchor positioning, o popover nativo ainda pode abrir. A camada nova melhora a posição sem transformar sua ausência em falha funcional.

3. A posição do scroll pode dirigir a animação

.timeline {  overflow-x: auto;  scroll-snap-type: inline mandatory;  scroll-timeline: --history inline;}.progress {  transform-origin: left;  animation: fill linear both;  animation-timeline: --history;}@keyframes fill {  from { scale: 0.05 1; }  to { scale: 1 1; }}

Não há evento scroll, cálculo manual de porcentagem nem requestAnimationFrame. Sem a timeline, o conteúdo continua rolável e o scroll-snap continua útil. O efeito é progressivo.

O experimento que não cabia em uma coleção de snippets

Snippets separados mostram sintaxe. Eles não provam que os recursos conseguem formar uma interface coerente.

Por isso construí o Observatório CSS 2026, uma central interativa que combina nove capacidades em um único sistema:

1. container queries;
2. :has();
3. estados nativos com :checked, :open e :target;
4. animações guiadas pelo scroll;
5. anchor positioning e popover;
6. navegação por fragmentos;
7. motion path;
8. clip-path com shape() progressivo;
9. OKLCH, color-mix() e contrast-color().

Os controles usam HTML nativo. Não há JavaScript mantendo o estado das interações. O componente também preserva conteúdo e operação quando uma camada recente não está disponível, funciona por teclado e respeita prefers-reduced-motion.

Você pode testar a interface aqui:

Abrir o Observatório CSS 2026 e testar as nove capacidades

O critério que uso antes de colocar CSS novo em produção

Uma demonstração impressionante ainda não é uma decisão de produto. Para cada recurso, faço cinco perguntas:

1. Qual é a fonte da afirmação? Localizo o módulo, seu estágio e documentação de compatibilidade datada.
2. A funcionalidade é essencial ou progressiva? Comprar, autenticar e ler exigem um limiar diferente de uma transição visual.
3. Qual tarefa permanece sem o recurso? Fallback deve preservar informação e operação, não necessariamente reproduzir cada pixel.
4. A matriz genérica representa meus usuários? Baseline não conhece WebViews antigas, políticas corporativas nem os dados reais do seu produto.
5. Quando essa decisão será revista? Registro data, navegadores testados, fallback e condição para removê-lo.

O princípio é simples:

.feature {  /* Base legível e funcional para todos. */}@supports (position-anchor: --menu-trigger) {  .feature {    /* Melhoria aplicada somente quando a capacidade existe. */  }}

CSS moderno não elimina fundamentos. Ele recompensa HTML semântico, cascade compreendida, acessibilidade e fallbacks deliberados.

Então qual versão do CSS você usa?

Na maioria dos projetos, a resposta mais honesta é apenas CSS.

Quando precisar de precisão, cite o recurso ou o módulo: container queries, Selectors Level 4, CSS Color 4, Cascade Layers. Se a conversa for sobre adoção, acrescente o estado Baseline e os browsers realmente testados.

CSS4 não virou o sucessor oficial de CSS3. CSS5 também não. Ao mesmo tempo, níveis 4 e 5 são reais dentro dos módulos, e existe até um grupo comunitário discutindo CSS4 como rótulo didático, separado das normas oficiais.

O leitor que questionou meu texto antigo tinha razão sobre o problema central: dizer somente que CSS4 não existe já não explica o CSS que usamos hoje.

A versão completa reúne a história, a distinção entre os níveis, as fontes verificadas em setembro de 2026, os nove exemplos, os fallbacks e o Observatório funcionando no navegador:

Ler o artigo completo e experimentar o CSS de 2026

Qual desses recursos mudou mais a forma como você escreve CSS? E qual ainda parece cedo demais para o seu ambiente de produção?

Passei os últimos meses construindo um projeto pessoal e ele chegou na v1.0, então resolvi compartilhar.

O atomicvulns é uma coleção de apps web propositalmente vulneráveis, mas com uma ideia diferente: cada app isola uma única vulnerabilidade, nada além disso. Em vez de um sistema gigante cheio de falhas (tipo DVWA ou Juice Shop), aqui cada exercício é pequeno e focado — você lê o código, vê a causa, explora, e compara com a versão corrigida ao lado.

Cada "átomo" vem com o app vulnerável, o app corrigido, um diff comentado entre os dois, e um walkthrough do exploit passo a passo. A v1.0 cobre as 10 categorias do OWASP Top 10 2021 com 38 átomos no total.

É pra quem está estudando pentest / AppSec e já manja o básico de HTTP e terminal, o Burp Suite é a ferramenta principal em todos os walkthroughs.

Alguns detalhes:

• Open source (MIT).
• Bilíngue — toda a documentação em inglês e português, porque senti falta de material assim pra quem estuda em PT-BR.
• Projeto solo, feito por mim. Meu foco foi ter um lugar onde cada falha fica clara e isolada, o material que eu queria ter tido enquanto estudava e aprendia pentest web.
• Construído em par com IA, com cada átomo validado por mim rodando o exploit na mão.

Fiz pra mim, mas agora que está pronto, se ajudar mais alguém no caminho, ótimo.

🔗 https://github.com/doretox/atomicvulns

O próximo salto é dar a ela contexto, ferramentas e memória

Você abre o ChatGPT, escreve um prompt, recebe uma resposta e fecha a aba. Parece que está usando IA. Mas, na prática, você apenas trocou a caixa de busca por uma caixa de conversa.

Nos últimos meses, montei um sistema em que a IA não apenas responde: ela encontra o que precisa e executa o trabalho. Na edição de hoje da Newsletter do Moa, vou abrir essa arquitetura em detalhes para você copiar.

Meu setup de IA não está no meu computador

Semana passada, eu estava conversando com meu amigo Henrique Bastos sobre como tenho usado inteligência artificial no meu dia a dia.

Em algum momento, contei que uso o 1Password para guardar as credenciais de que minhas ferramentas de IA precisam. A ideia é simples: em vez de colocar uma chave de API dentro de um projeto ou entregar a chave para a IA, eu guardo tudo no 1Password e peço à IA para acessar aquela credencial somente no momento em que precisa usá-la.

O Henrique ficou interessado. Comentou que esse também era um problema para ele e gostou da solução. Então, me pediu para compartilhar em mais detalhes como estou usando IA, buscando outros insights como esse.

Quando comecei a organizar as ideias, percebi que o que eu construí nos últimos meses foi uma forma estruturada de usar IA. Eu não a uso mais apenas como uma aplicação que abro no computador quando preciso de ajuda. Ela virou uma camada operacional da minha vida e do meu trabalho.

Neste momento, por exemplo, estou falando com a IA pelo celular. Estou usando a minha voz para interagir com ela e elaborar este texto. Não estou com o notebook aberto, não digitei nada, não abri um terminal, não procurei arquivos e não fiz nada “manualmente”. Apenas expliquei o que queria.

Essa simplicidade só é possível porque, por trás dessa conversa, existe uma infraestrutura capaz de acessar meus projetos, consultar documentação, recuperar contexto e transformar o que estou dizendo em trabalho. Nos próximos parágrafos, vou te apresentar essa estrutura detalhadamente.

O lugar do trabalho migrou

Vamos começar pelo começo. A base do meu setup é um pequeno servidor que fica ligado na tomada 24/7, lá no meu escritório. Ele roda num Lenovo ThinkCentre usado, que paguei menos de mil reais na OLX. O batizei de Olimpo, e é nele que vive boa parte do meu ambiente de IA.

Meu notebook e meu celular funcionam como pontos de acesso. Posso começar uma tarefa no computador, fechar a tampa e continuar depois pelo celular. Os processos não dependem de uma janela aberta no meu Mac. Eles não rodam mais na minha máquina, mas sim num servidor, independentemente de onde eu estiver.

Essa liberdade é o que permite usar um celular como uma interface real de trabalho. O telefone não precisa guardar meus projetos, executar ferramentas ou ter grande capacidade de processamento. Ele precisa apenas me conectar a um ambiente que já possui tudo isso.

Eu praticamente não digito mais

Eu ainda uso o notebook, claro. Prefiro mil vezes trabalhar por ele do que pelo celular. Sem contar que existem ainda algumas poucas atividades em que a IA precisa controlar aplicativos ou até mesmo o browser, e na minha máquina fica mais fácil.

Mas, confesso que a maior parte do meu trabalho hoje acontece pela voz. Enquanto caminho, estou no carro ou longe da mesa, posso explicar um problema, desenvolver uma ideia ou pedir uma análise. Falar permite transmitir muito mais contexto do que eu provavelmente escreveria num prompt.

O ponto mais importante é que eu não preciso ditar comandos. Eu não preciso dizer para a IA entrar em determinado diretório, abrir três arquivos, executar uma busca e consultar uma API. Posso falar no nível da minha intenção: “Quero entender como está a operação comercial”; “Procura aquela conversa que tive com uma pessoa”; “Transforma esta ideia num texto”; “Avalie esse problema levando em conta o que já decidimos”.

A IA traduz essa intenção em ações menores. Por isso, a voz não é apenas uma forma conveniente de escrever prompts. Ela funciona como uma linguagem operacional. Eu falo sobre o problema; o sistema lida com arquivos, comandos, bases de dados e serviços.

Isso também depende da qualidade dos modelos que uso. Hoje só trabalho usando modelos avançados da OpenAI, como o Sol (ainda quero testar o Astra).

O Codex é meu motor de trabalho

Quando falo que uso o notebook ou o celular para trabalhar, a interface que aparece para mim é o aplicativo do ChatGPT. Tenho o aplicativo instalado nos dois dispositivos e, dentro deles, configurei uma conexão SSH. O motor de trabalho é o Codex.

Quando começo uma conversa, existe por trás dela uma instância do Codex operando dentro do servidor. É o Codex que acessa meus projetos, lê arquivos, executa comandos, chama outras ferramentas e realiza o trabalho que pedi. O aplicativo do ChatGPT é a interface que me leva até esse ambiente.

Dentro do Olimpo existe um ambiente que chamo de Devbox. Ele é minha estação remota de desenvolvimento e de trabalho com IA. É ali que ficam os agentes, as ferramentas de linha de comando e os projetos que uso com mais frequência. Uso o Tailscale como ferramenta de VPN para poder acessar esse ambiente sem expor o servidor diretamente na internet.

Em termos simples: o ChatGPT é a interface, o Codex é o agente, o Sol é o modelo, o Devbox é o ambiente de execução e o Olimpo é a máquina física onde tudo isso vive.
Cada capacidade tem seu próprio ambiente
O Olimpo não é um servidor com tudo instalado junto. Uso o Proxmox para separar as funções em containers. Existe um ambiente para desenvolvimento, outro para WhatsApp, outro para Discord, outro para monitoramento e outros para tarefas específicas.

Um container roda o WAHA, que conecta minhas contas de WhatsApp. Outro roda o Discord Manager, que guarda o histórico do servidor do Tintim e o disponibiliza para a IA. Há duas instâncias do Hermes, um agente pessoal que pode funcionar pelo Telegram. Uma é minha; a outra é da minha esposa, com ferramentas e permissões diferentes. Também existem containers para automações, monitoramento, mídia e downloads.

Essa separação me permite adicionar capacidades sem transformar o servidor inteiro. Quando surge uma necessidade, posso criar uma peça especializada e ensinar os agentes a usá-la.

Se um serviço falha, o restante não precisa parar. Se preciso atualizar uma ferramenta, consigo trabalhar naquele ambiente específico. E cada agente acessa apenas aquilo que faz sentido para sua função.

Os projetos explicam o trabalho a ser feito

Dar acesso a arquivos e ferramentas não é suficiente. Para trabalhar bem, a IA precisa entender o contexto de cada projeto. Precisa saber o que está sendo construído, quais decisões já foram tomadas, quais regras deve seguir e o que não pode fazer. Por isso, tenho um repositório GitHub para cada projeto.

No projeto onde controlo minhas finanças, por exemplo, existem regras de segurança, conciliação e revisão. No projeto em que gerencio meu canal do YouTube, existem critérios editoriais e processos para preparar vídeos. Num projeto de inteligência comercial que estou criando para o Tintim, existem perguntas, fontes, hipóteses e evidências. No próprio projeto do Olimpo está documentado como cada serviço foi instalado e como deve ser operado.

As skills globais entram como uma extensão disso. Elas estão disponíveis para todos os projetos e facilitam a interação deles com o mundo externo. Tenho skills para consultar o Notion, acessar o Google Workspace, buscar conversas no WhatsApp, ler o Discord, consultar bases de dados, transcrever áudios e trabalhar com vários outros serviços.

Elas também definem limites. Algumas ferramentas são deliberadamente somente leitura. A IA consegue consultar e analisar, mas a própria ferramenta não oferece operações para modificar os dados.

Essa organização reduz a quantidade de instruções que preciso dar em cada conversa. Em vez de explicar novamente como um processo funciona, eu mantenho esse conhecimento junto do sistema. Quando eu falo, o projeto e as skills completam o contexto que não foi dito.

A memória atravessa as conversas

Ainda existe outro tipo de contexto que não pertence a um projeto específico. Quem sou eu? O que está acontecendo na empresa? Quais decisões tomei? Que tensões continuam abertas? Quando mencionei determinado assunto pela última vez?

Uso dois sistemas principais para isso. O Second Brain é meu vault no Obsidian. Nele guardo acontecimentos, ideias, pessoas, reuniões e materiais da minha vida e do meu trabalho. O Mirror Mind cuida da continuidade da relação com os agentes. Ele também mantém minha identidade, minhas jornadas, decisões, padrões e diferentes formas de olhar para um problema.

Os projetos explicam como o trabalho deve ser feito. O Second Brain guarda o que aconteceu. O Mirror ajuda a IA a entender de que trajetória aquela conversa faz parte.

Isso permite que eu fale de uma forma muito mais natural. Posso dizer “aquela conversa com o Henrique”, “o problema da semana passada” ou “continua a tese que estávamos construindo”. A IA sabe do que eu estou falando porque tem contexto.
Usar os sistemas sem entregar as chaves

Eu uso IA somente no modo YOLO. Não vejo sentido se não for pra ser assim. Mas, como diria Uncle Ben: “Com grandes poderes, vêm grandes responsabilidades”. Por isso, eu tenho um cuidado extra relacionado à segurança das senhas e chaves de que os agentes precisam para usar todos esses serviços.

Para consultar uma API, acessar uma base de dados ou operar um serviço, geralmente é necessário algum tipo de credencial. A solução mais simples seria colocar essas chaves em arquivos de configuração dentro dos projetos. Eu não faço isso.

O que faço é usar o 1Password como fonte de verdade para os segredos. A skill sabe qual credencial precisa, onde ela está e em qual variável deve ser injetada. Quando a ferramenta é executada, o 1Password fornece o segredo apenas para aquele processo. A IA não recebe o valor da credencial. A chave não precisa aparecer no prompt, no código, no histórico do terminal ou no repositório.

No Discord Manager, por exemplo, o token sai do 1Password, atravessa uma conexão SSH e é armazenado como uma credencial criptografada do systemd dentro do container. O valor não fica num .env.

Processos 100% autônomos e confiáveis

A beleza de se ter um setup desse é que ele é 100% moldável pela própria IA. Isso significa poder ter diversos sistemas e rotinas rodando de forma autônoma, sem que eu precise interagir ativamente. O próprio setup, inclusive, foi criado quase que 100% pela IA.

No setup, eu tenho várias rotinas automatizadas. Há rotinas que sincronizam projetos, fazem backup, importam anotações de reuniões, atualizam meu Second Brain ou cuidam de tarefas no servidor.

Mas como saber se essas rotinas estão funcionando corretamente? Simples. Quando uma automação funciona normalmente, eu não preciso ficar sabendo de nada. Agora, quando falha, recebo uma mensagem pelo Telegram. Se um processo parar de enviar seu sinal periódico de saúde, o monitor detecta. Se um serviço cair, recebo um alerta. Se algo der errado, existem logs para investigar.

Uso o Uptime Kuma para monitorar serviços e receber heartbeats das automações. Os processos deixam logs, usam locks para evitar execuções sobrepostas e são executados por timers do systemd.

O que existe por trás das conversas

Até aqui, expliquei os princípios por trás da arquitetura. Para tornar isso mais concreto, esta é uma fotografia do que existe hoje no meu setup. Não é uma recomendação para que todo mundo instale as mesmas coisas. É apenas o sistema que foi surgindo conforme minhas necessidades apareceram. Estou te mostrando para te alimentar de referências.

Os ambientes

Tecnicamente, a maior parte desses ambientes é composta por containers LXC, embora no dia a dia eu pense neles como pequenas máquinas separadas.

Olimpo: é o servidor físico. Roda Proxmox, compartilha os discos pela rede, fornece acesso remoto pelo Tailscale e hospeda todos os outros ambientes.

Devbox: é a minha estação remota de trabalho. É onde o Codex opera, onde estão os projetos e onde ficam instaladas as principais ferramentas usadas pelos agentes.

WAHA: conecta minhas contas pessoal e Business do WhatsApp, permitindo que os agentes consultem minhas conversas.

Discord Manager: mantém uma cópia local do histórico do Discord da Tintim e oferece ferramentas para pesquisar mensagens, acompanhar menções, criar bookmarks e responder conversas.

Automações: executa pequenas rotinas recorrentes, como backups e integrações entre os serviços.

Uptime Kuma: monitora a disponibilidade dos serviços e os sinais periódicos enviados pelas automações. Quando alguma coisa para de funcionar, ele dispara um alerta.

Jellyfin: organiza e reproduz minha biblioteca de filmes e séries. Também possui as ferramentas usadas para baixar e sincronizar legendas.

qBittorrent e Jackett: cuidam da busca e do download de filmes e séries, salvando os arquivos diretamente na biblioteca usada pelo Jellyfin.

As skills globais

As skills ensinam o Codex a usar cada serviço. Elas descrevem qual ferramenta deve ser chamada, como a autenticação funciona, quais operações são permitidas e como o resultado deve ser interpretado.

1Password: localiza e injeta credenciais nos processos sem expor seus valores para a IA ou salvá-los nos projetos.

Apify: executa e administra Actors de coleta e processamento de dados na nuvem.
Asaas: consulta clientes, cobranças, assinaturas, pagamentos, saldo e outras informações financeiras. A skill é somente leitura.

Discord Manager: permite pesquisar o histórico do Discord da Tintim, acompanhar mensagens e menções, organizar bookmarks e enviar respostas.

Firecrawl: pesquisa e extrai informações da web. Dependendo da tarefa, pode buscar páginas, navegar por sites, interagir com interfaces, coletar dados estruturados ou produzir pesquisas mais extensas.

GitHub: permite trabalhar com repositórios, issues, pull requests, Actions e releases.
Google Workspace: acessa Drive, Docs, Sheets, Gmail, Calendar, Meet e outros serviços do Google.

Kommo: recupera e resume o histórico de conversas dos leads no CRM da Tintim. É somente leitura.

Make: consulta cenários, execuções, webhooks, conexões e outros recursos da nossa conta do Make.

Notion: pesquisa, lê e edita páginas e bases do Notion.
WhatsApp: pesquisa conversas, mensagens, contatos e grupos nas minhas contas pessoal e Business.

Além dessas, cada projeto pode ter suas próprias skills. O projeto do Olimpo, por exemplo, possui uma skill que coordena Jackett, qBittorrent, Jellyfin e as ferramentas de legenda parabaixar um filme ou episódio inteiro a partir de um pedido em linguagem natural.

Os projetos

Os projetos guardam tanto o trabalho quanto o contexto necessário para realizá-lo. Estes são os principais repositórios que existem hoje na minha Devbox:

Olimpo: documenta e versiona a infraestrutura do meu servidor, seus serviços, instalações, automações e decisões operacionais.

Second Brain: é meu vault pessoal no Obsidian, onde guardo acontecimentos, reuniões, pessoas, ideias e materiais da minha vida e do meu trabalho.

Mirror Mind: é o sistema de memória e identidade que mantém continuidade entre minhas conversas, decisões e jornadas.

Canal do Moa: reúne os processos editoriais e as automações usadas para preparar vídeos, criar leads, selecionar recomendações e conectar o canal à newsletter.
Newsletter do Moa: contém as skills e os agentes usados no processo semanal de produção da newsletter.

Financeiro: é meu controle financeiro pessoal, construído sobre Beancount.
Inteligência Comercial: reúne fontes, evidências e investigações sobre a máquina comercial da Tintim, da aquisição do lead até a venda.

Product Management: é o segundo cérebro de produto da Tintim, com pesquisas, dados, decisões e conhecimento sobre clientes e produto.

Essa lista mostra que acessar meus projetos não significa apenas programar. A IA transita entre infraestrutura, finanças, produto, conteúdo, memória pessoal e operação da empresa.
A IA como camada operacional

O que mais me interessa nessa arquitetura não é o servidor, o Proxmox ou qualquer ferramenta isolada. É a relação que o conjunto permite.

Eu expresso uma intenção. A IA encontra o contexto, escolhe uma capacidade, acessa os sistemas necessários e realiza o trabalho. Dependendo da tarefa, ela pode ler arquivos, consultar uma base, procurar uma conversa, recuperar uma reunião ou modificar um projeto. Meu notebook e meu celular são formas diferentes de entrar nessa camada. Na maior parte do tempo, eu entro falando.

Isso não elimina o trabalho. Eu ainda preciso formular bem os problemas, revisar decisões e assumir responsabilidade pelo que é feito. A diferença é que não preciso operar pessoalmente cada etapa intermediária.

A mudança mais importante não foi instalar uma IA mais inteligente. Foi construir um ambiente no qual ela consegue trabalhar de forma contínua, contextualizada e segura.

Cansei do Windows vir cheio de coisa que eu nunca pedi: IA ligada sem eu querer, telemetria que nao da pra ver direito, bloatware que fico desinstalando toda vez que formato uma maquina. Entao fiz um kit PowerShell que desliga tudo isso de uma vez, em Windows 10 e 11.

O que faz

O win-mute tem 72 ajustes em 6 categorias:

• AI: Copilot, Recall, Click To Do, Cortana, busca do Bing, IA generativa, Destaques de busca, Suggested Actions do clipboard
• Telemetry: nivel de dado de diagnostico, DiagTrack, ID de publicidade, historico de atividades, CEIP, relatorio de erro
• Services: Retail Demo, Maps broker, Fax, indexacao da busca, Remote Registry, servicos do Xbox
• ScheduledTasks: CEIP, Application Experience, prompt de feedback, telemetria do autochk
• Bloatware: 25 apps de fabrica (Xbox, Bing Weather/News, Solitaire, Skype, Teams consumer, etc)
• Privacy: anuncio no Iniciar/tela de bloqueio, secao "Recomendados", menu de clique direito classico, icone de Chat, Widgets, nag do OneDrive, instalacao automatica de app patrocinado, entre outros

Cada ajuste e um objeto PowerShell simples com blocos Apply, Revert e Test, mexendo nos mesmos pontos que ferramenta fechada tipo essa mexe: chave de registro de Group Policy, tipo de inicializacao de servico, tarefa agendada, remocao de pacote Appx. Nada escondido, da pra abrir modules/*.ps1 e ler cada um antes de rodar.

Pesquisei reclamacao real antes de escrever o codigo

Em vez de chutar quais ajustes importam, pesquisei o que usuario de Windows realmente reclama (Reddit, imprensa tech, 2025-2026), em duas rodadas:

• Revolta contra Windows 11: menu de clique direito capado, anuncio no Menu Iniciar, feed "Recomendados" forcado, icone de Chat na taskbar, app patrocinado se instalando sozinho.
• Dor especifica do Windows 10 (pos fim de suporte, out/2025): nag insistente de upgrade pro Windows 11 pra quem fica no 10 usando ESU, Bing sequestrando a busca da taskbar, icone de Pessoas que ninguem pediu, Edge recriando atalho na area de trabalho toda hora.

Windows 10 ou 11, detectado sozinho

Sem escolher versao na mao. O script confere o numero de build e os ajustes que so existem numa versao (Copilot, Recall, o menu de contexto classico, Widgets) somem sozinhos na outra. 64 dos 72 ajustes valem no Windows 10, 70 no Windows 11.

CLI e GUI

# Lista interativa.\Invoke-WinMute.ps1# Sem prompt, uma ou mais categorias.\Invoke-WinMute.ps1 -Categories AI,Telemetry -All# So o que nao tem efeito colateral nenhum.\Invoke-WinMute.ps1 -All -SafeOnly# Reverte tudo.\Invoke-WinMute.ps1 -Undo

Pra quem nao quer mexer com PowerShell, o START-GUI.bat abre uma janela WPF que se auto-eleva, mostra um botao grande "Aplicar agora" com os ajustes seguros recomendados, e deixa a lista completa escondida atras de "Personalizar". Troca entre portugues e ingles com um clique, sem reabrir a janela.

A pergunta "vou perder alguma coisa?"

Reconferi os 72 ajustes pensando exatamente nisso. Nenhum toca em arquivo pessoal, so mexe em valor de registro, tipo de inicializacao de servico, estado de tarefa agendada, ou desinstala app da Store (remove so a config local daquele app, nunca Documentos ou foto). Achei um caso real na auditoria: forcar "apps em segundo plano" desligado pra todo mundo pode parar notificacao de app de mensagem/email, entao tirei esse do grupo "Seguro" e passei pra "Moderado" em vez de deixar no clique unico. Por padrao a ferramenta cria um ponto de restauracao do Windows antes de qualquer mudanca, como rede de seguranca extra.

Uma coisa que deixei de fora de proposito: atualizacao forcada e reinicio automatico do Windows. Desligar isso troca incomodo de interface por PC sem patch de seguranca, e essa troca nao vale a pena nem no -All.

Codigo aberto, licenca MIT, so PowerShell, sem dependencia externa. Repo: https://github.com/obrenoalvim/win-mute

Qual "funcionalidade" do Windows voce desligaria primeiro se pudesse?

Ps.: Desenvolvo o BloodLink, plataforma gratuita que conecta doadores de sangue a campanhas de doacao. Se quiser conhecer, vale a visita.

Estava testando MCPs e queria conectar um servidor MCP rodando localmente ao ChatGPT, sem precisar expor o servidor diretamente à Internet.

Acabei descobrindo o Secure MCP Tunnel da OpenAI.

A arquitetura ficou basicamente:

ChatGPT
↓
Secure MCP Tunnel
↓
tunnel-client
↓
MCP local

Para testar, usei um MCP de terceiros para o LinkedIn e consegui utilizar suas ferramentas pelo ChatGPT enquanto o MCP continuava rodando na minha máquina.

Achei interessante principalmente pela possibilidade de desenvolver e testar MCPs localmente sem precisar publicar um endpoint HTTP só para fazer a integração.

Documentei o processo, incluindo configuração, comandos e algumas considerações de segurança:

Como conectar um MCP local ao ChatGPT usando o Secure MCP Tunnel

Aviso: o "mcp-server-linkedin" utilizado no exemplo é um projeto de terceiros. Não é desenvolvido nem verificado pela OpenAI ou pelo LinkedIn, e seu uso é de responsabilidade de quem o executa. O LinkedIn possui restrições quanto a scraping e automações, então vale entender bem o que você está executando antes de utilizá-lo.

Olá, pessoas!

Recentemente voltei a estudar design de linguagens de programação. Acho que é um conhecimento que vale a pena pra qualquer programador, independente da área: entender não só por cima, mas também por baixo dos panos, como as linguagens funcionam, como são construídas e como rodam. Pode ser que você nunca chegue a usar esse conhecimento no dia a dia, mas isso não é motivo pra deixar de aprender.

Crafting Interpreters

Se você quer começar a entender e construir suas próprias linguagens, recomendo demais o Crafting Interpreters. É uma das portas de entrada mais didáticas que existem no assunto.

Confesso que a minha primeira linguagem não nasceu da leitura do livro, e sim depois de ver o Alexey Kutepov, o Tsoding, construindo uma linguagem stack-based inspirada em Forth em Python. Fui atrás e criei a Beremiz, uma stack-based feita em Lua, inspirada no Porth do próprio Tsoding.

E aí entra a Codice

Dessa vez decidi construir uma linguagem com sintaxe "c-like". Chamei ela de Codice, "código" em italiano.

A ideia por trás do nome não é só estética: ao mesmo tempo que exercito conhecimento de construção de linguagens, aproveito pra estudar italiano, já que todas as palavras-chave, mensagens de erro e nomes de conceitos da linguagem são em italiano. E quem sabe também sirva de porta de entrada pra falantes do idioma que queiram aprender programação, do mesmo jeito que temos o Portugol, a Égua, o Delégua e o Birl para o português:

• https://pt.wikipedia.org/wiki/Portugol
• https://egua.dev/
• https://github.com/designLiquido/delegua
• https://birl-language.github.io/

Por que PHP?

Porque a Codice não tem nenhuma ambição de ser uma linguagem útil ou com aplicação real, é uma toy language, feita por diversão e aprendizado. Muita gente que está começando na programação acha que precisa aprender ferramentas ou linguagens específicas pra "poder" construir certas coisas, quando na real você pode validar qualquer ideia na linguagem que você já conhece, do seu jeito.

Óbvio que uma linguagem interpretada em PHP nunca vai ter a performance de algo feito "do jeito certo", mas performance nunca foi o objetivo aqui. Depois de madura, nada impede a Codice de ser reescrita em outra linguagem, compilada para bytecode ou até rodando sobre a JVM (o que, aliás, pretendo fazer no futuro).

Um gostinho da sintaxe

Hoje a Codice já tem lexer, parser e um interpretador tree-walking rodando de ponta a ponta, com tipos stringa, booleano, nullo, intero e decimale:

stampa("Interi: ", 42, ", ", 1_000_000);stampa("Decimali: ", 3.14, ", ", .5, ", ", 1_234.567_89, ", ", 67.);stampa("Booleani: ", vero, ", ", falso);stampa("Nullo: ", nullo);

Saída:

Interi: 42, 1000000Decimali: 3.14, 0.5, 1234.56789, 67.0Booleani: vero, falsoNullo: nullo

Ainda não tem variáveis, controle de fluxo nem funções definidas pelo usuário, ainda está bem no início. Mas o pipeline completo já funciona, incluindo um REPL simples.

Acompanhe o desenvolvimento

O código está no meu GitHub, aberto e público: https://github.com/AdaiasMagdiel/codice

É isso, galera. Até mais e obrigado pelos peixes!

Trabalho com desenvolvimento há tempo suficiente para já ter visto quase todo tipo de rebranding. Já vi empresa trocar o logo e chamar isso de transformação digital. Já vi sistema ganhar gradiente porque alguém descobriu o Figma. Já vi botão mudar de azul para roxo e ser apresentado como uma nova fase da marca.

Nada disso me preparou para fazer o rebranding de uma plataforma com inteligência artificial.

O problema agora é outro: não basta deixar a interface bonita. Ela precisa parecer que foi pensada por alguém.

O problema do design genericamente correto

A IA não costuma produzir interfaces feias. Ela produz interfaces genericamente aceitáveis.

Cards brancos, sombra suave, ícones lineares, botão “Get started”. Tudo correto — e completamente esquecível.

O feio chama atenção. O genérico passa pela revisão e, meses depois, ninguém sabe por que o produto parece igual a todos os outros.

Consistência é importante, mas consistência demais também denuncia. Quando toda página usa o mesmo card, borda e botão, o design system começa a parecer uma fórmula.

Rebranding não é trocar cores

Rebranding não é escolher uma paleta e renomear componentes.

É decidir o que o produto comunica sem precisar explicar.

É saber se um botão deve ser preto, verde ou vermelho. Se um card precisa de borda. Se uma tela precisa de ajuda textual ou apenas de mais espaço.

Essas decisões parecem pequenas até você aplicá-las numa plataforma que já existe.

Porque plataformas antigas têm história: CSS local, componentes duplicados, inputs com alturas diferentes, modais copiados e props usadas de maneiras que ninguém planejou.

A pergunta começa inocente:

“Podemos deixar tudo mais consistente?”

A resposta é “sim” — até alguém abrir o forro.

O perigo do componente universal

Quando a IA encontra inconsistências, uma solução comum é criar um componente universal.

Ele recebe variant, size, tone, mode, density, state, layout, loading, intent e mais algumas props que serão documentadas depois.

Na teoria, resolve tudo. Na prática, nasce o UniversalSurfaceActionField.vue com 900 linhas.

O problema é abstrair antes de entender o que realmente é compartilhado. Nem tudo que aparece duas vezes é o mesmo componente.

Minimalismo não é vazio

Minimalismo não é remover informação até o usuário precisar abrir o DevTools para entender o que aconteceu.

É redução consciente: tirar ruído sem tirar contexto.

Na nossa paleta, usamos neutros, preto suave e verde-lima ácido. O verde carrega identidade, o preto sustenta ações normais, o branco dá espaço e os cinzas separam informação sem cercar tudo de bordas.

Mas o accent não pode virar passe livre para pintar tudo.

Se botão, foco, badge, sucesso, link e ícone usam a mesma cor forte, ela deixa de indicar prioridade e vira decoração.

Nem tudo precisa pedir atenção ao mesmo tempo.

Dar nome à intenção

Numa auditoria visual, é comum descobrir quatro tamanhos de input sem ninguém ter decidido que deveriam existir quatro tamanhos.

Um tem 36px porque cabe numa tabela, outro 40px porque parece confortável, outro 44px porque veio do componente certo e outro 48px porque alguém confundiu destaque com volume.

A solução é criar uma escala semântica:

• sm: tabelas e contextos densos;
• compact: formulários menores;
• md: padrão da plataforma;
• lg: áreas de destaque.

Não é sobre decorar pixels. É sobre dar nome à intenção.

Quando a regra existe, a IA ajuda. Quando não existe, ela só escolhe números que parecem razoáveis.

Onde a IA realmente ajuda

A IA é excelente para auditoria.

Pode encontrar componentes duplicados, props não utilizadas, strings hardcoded e estilos fora do padrão.

Mas alguém ainda precisa perguntar:

Isso descreve o produto ou só descreve o código?

Código organizado não garante produto coerente.

Um botão preto numa tela, verde em outra e vermelho numa terceira não derruba o sistema.

Mas, juntos, esses detalhes passam uma mensagem clara:

ninguém está no controle.

Rebranding é recuperar esse controle sem fingir que o passado não existe. É preservar o que funciona, substituir o que confunde e documentar o que não pode quebrar.

Velocidade não é direção

A IA pode gerar cem opções antes do café. Isso não significa que alguma delas saiba para onde o produto está indo.

Direção continua sendo trabalho humano.

É escolher uma cor e sustentar a escolha. Remover uma borda e confiar no espaço. Rejeitar um card bonito porque ele não explica nada. Olhar para um layout tecnicamente perfeito e dizer:

“Isso está com cara de template.”

E saber explicar por quê.

No fim, o maior desafio é criar uma interface em que a IA esteja presente no produto, mas ausente da caligrafia visual.

Uma interface clara e coerente, com componentes que têm propósito e exceções que têm motivo.

Porque uma boa identidade não é a que impressiona no primeiro screenshot, mas a que continua fazendo sentido depois de centenas de telas.

No fim, rebranding é menos sobre parecer novo e mais sobre parar de parecer acidental.

Ve la se tem cara de artefato do Claude > https://vidnap.com

Somos a equipe do Weydub, uma ferramenta de localização de vídeo. Este texto apresenta uma decisão técnica do fluxo documentado publicamente: separar a detecção de texto da decisão de remover pixels. A redação e a tradução tiveram assistência de IA. O código abaixo é um exemplo didático executado localmente; não é o código interno do produto nem um teste da qualidade de restauração.

Três operações que não são equivalentes

Uma legenda pode existir como faixa separada no contêiner do vídeo ou estar gravada nos pixels. Excluir a faixa não remove os caracteres que já fazem parte da imagem. Nesse segundo caso, é necessário identificar a área e reconstruir seu conteúdo visual.

OCR responde a “que texto aparece nesta imagem?”. Ele não responde sozinho a “este texto deve desaparecer?”. Em uma aula gravada, por exemplo, a legenda da fala pode ocupar a parte inferior, enquanto uma fórmula no quadro deve permanecer. Uma seleção baseada apenas na existência de texto pode destruir informação útil.

A geração de legendas também é outra tarefa. OCR extrai texto visível; ASR reconhece a fala. Na documentação do Weydub são modos separados, não uma fusão automática. A tradução e a dublagem vêm com decisões adicionais: identidade dos personagens, continuidade da voz e duração das falas.

Da caixa detectada para uma decisão com limites

Uma forma de reduzir ambiguidade na integração é representar explicitamente a região e o intervalo de tempo. Isso não garante que a escolha esteja correta; torna a escolha inspecionável antes de executar uma operação sobre o vídeo.

Neste exemplo usamos um vídeo hipotético de 640 × 360 pixels e 12 segundos. A caixa vai de (64, 270) a (576, 342), mas a intervenção vale apenas entre os segundos 3 e 8. As coordenadas normalizadas são [[0.1, 0.75], [0.9, 0.75], [0.9, 0.95], [0.1, 0.95]].

Salve o exemplo como mask-example.mjs e execute com Node.js:

import assert from 'node:assert/strict';function makeMask({ width, height, box, start, end, duration }) {  const values = [width, height, ...box, start, end, duration];  if (!values.every(Number.isFinite)) throw new Error('Non-finite value');  const [x0, y0, x1, y1] = box;  if (width <= 0 || height <= 0 || x0 < 0 || y0 < 0 ||      x1 > width || y1 > height || x0 >= x1 || y0 >= y1 ||      start < 0 || end <= start || end > duration) {    throw new Error('Invalid region or time interval');  }  return {    type: 'remove_only_ocr', start, end,    region: [[x0 / width, y0 / height], [x1 / width, y0 / height],      [x1 / width, y1 / height], [x0 / width, y1 / height]],  };}const input = { width: 640, height: 360, box: [64, 270, 576, 342], start: 3, end: 8, duration: 12 };const mask = makeMask(input);assert.deepEqual(mask.region, [[0.1, 0.75], [0.9, 0.75], [0.9, 0.95], [0.1, 0.95]]);const payload = { needChineseOcclude: 2, videoInpaintMasks: JSON.stringify([mask]) };assert.deepEqual(JSON.parse(payload.videoInpaintMasks), [mask]);assert.throws(() => makeMask({ ...input, width: 0 }));assert.throws(() => makeMask({ ...input, box: [576, 270, 64, 342] }));assert.throws(() => makeMask({ ...input, end: 13 }));assert.throws(() => makeMask({ ...input, start: NaN }));console.log('PASS: coordinates; JSON round-trip; zero width; reversed box; time overflow; non-finite input');console.log(JSON.stringify(payload, null, 2));

A execução local passou pelas seis verificações acima. O campo videoInpaintMasks é serializado como string JSON conforme o contrato documentado, não enviado como um array diretamente. Os nomes dos campos foram mantidos como aparecem na API; o nome needChineseOcclude não deve ser interpretado como uma avaliação de qualidade por idioma.

O que esse teste não prova

Ele valida uma transformação de dados, não a detecção OCR nem o preenchimento da imagem. O exemplo assume uma caixa retangular de quatro números. Para entrada externa, ainda é necessário validar o formato do array, o esquema completo da requisição, a origem das coordenadas e a orientação do vídeo. Uma caixa obtida de um preview recortado não pode ser normalizada usando as dimensões do original sem desfazer o recorte.

O tempo também precisa usar a mesma referência do vídeo processado. Se um trecho foi extraído de um arquivo maior, um intervalo absoluto do original pode apontar para a cena errada no trecho. Aqui usamos segundos relativos ao vídeo hipotético de 12 segundos.

A revisão continua sendo parte do fluxo

Uma imagem isolada pode parecer boa e ainda apresentar cintilação durante a reprodução. Por isso, convém revisar movimento, cortes, rostos, mãos e contornos de produtos perto da região escolhida. Texto de cenário, avisos e fórmulas merecem uma decisão explícita de preservação. O resultado de uma ferramenta de preenchimento é uma reconstrução, não uma recuperação garantida dos pixels originais que estavam ocultos.

Para produzir uma nova versão em outro idioma, preserve separadamente o texto extraído e seus tempos. Revise a segmentação das legendas antes de traduzir. Na dublagem, confira a continuidade do personagem e a duração da fala em sequência, não apenas frase por frase.

Fontes e limites da apresentação

• Explicação pública sobre OCR e remoção de legendas
• Contrato da API de remoção
• Modos de geração por OCR e ASR
• Tradução e reconstrução audiovisual

Essas fontes são da própria equipe, não avaliações independentes. Elas explicam controles e problemas do fluxo; não divulgam toda a orquestração interna dos modelos. O exemplo não faz chamada paga nem envia vídeo. O Weydub em português é um serviço comercial com créditos; não estamos anunciando um plano gratuito nem apresentando números de precisão sem um experimento correspondente.

A contribuição que queremos deixar é esta: uma região reconhecida, uma política de edição e uma legenda temporizada são objetos diferentes. Mantê-los separados facilita testar a integração e revisar o que realmente será alterado.

E ai galera!

Há alguns anos tive o infortúnio de ser mandado embora por uma onda de layoff. Levei 6 meses para me recolocar, foi dolorido. Agora em 2026, a empresa que trabalho realizou cortes em massa também - desta vez permaneci no meu cargo, porém foi difícil ver colegas sendo afetados.

Tendo em vista essas experiências, pensei em trazer pra vocês 3 dicas práticas que me ajudaram a manter meu cargo nesse último corte massivo de gastos, que ajudam não só a manter a posição, mas também a evoluir dentro da empresa.

Antes das dicas de fato, também quero compartilhas sinais de que a sua empresa pode realizar um corte de gastos em breve:

Alertas de layoff 🚩

A) Compra ou fusão: esse é o maior alerta para cortes de gastos dentro de uma empresa. Uma empresa que foi comprada ou se fundiu com outra, com certeza vai realizar corte de gastos: reaproveitar recursos, seja espaço, ferramentas ou humanos, é uma das principais vantagens que leva as empresas a esses movimentos, reduzindo os custos operacionais

B) Pivô de produto: o descontinuamento de um produto parece óbvio como causa para um potencial layoff, mas as vezes mesmo uma mudança de abordagem ou paradigma para algum produto da empresa pode gerar esse efeito: passei por uma empresa que migrou sua solução de plataforma, indo de um software Desktop para um sistema web. Novos (poucos) programadores foram contratados para criar o sistema web, porém a área de implantação e suporte foi severamente reduzida com essa mudança

C) Tecnologias disruptivas: aqui como fator externo vem as mudanças tecnológicas do mercado. Atualmente estamos vivendo isso com a introdução da IA em nosso contexto de trabalho, mas a real é que isso é uma constante: profissionais de tecnologia estão na fronteira de inovação! Posso reforçar esse alerta com o exemplo das infraestruturas em "cloud", que removeu a necessidade de muitas empresas possuírem suas próprias estruturas de hospedagem com seus respectivos profissionais encarregados

E então o que fazer? 🟢

O cerne das 3 dicas que vou compartilhar vem daquela famosa frase: "é melhor prevenir do que remediar"

1. Foco em resultado

O principal é entender que quando você custa X para uma empresa, você deve gerar valor de X + Y% em retorno financeiro. Seu trabalho deve impactar positivamente os balanços contábeis da empresa.

Comece por entender como sua posição gera esse valor:

• São entregas pontuais, dentro do prazo estabelecido?
• São entregas altamente escaláveis?
• São entregas legalmente seguras?

Nem sempre o que você aprendeu na teoria vai ser o mais importante para o contexto atual. A arquitetura perfeito, o código 100% limpo, em troca de uma semana de atraso ou que não resolve o problema de fato....pode custar muito.

Quando você descobrir isso, souber que está gerando o X + Y% de retorno, pode ter certeza que dificilmente será mandado embora. E quanto maior o Y% for, maior moral você tem para argumentar um aumento!

2. Documente suas conquistas

Essa dica é muito valiosa, e você com certeza já deve ter ouvido de outra pessoa ou ainda vai ouvir bastante. Isso por que é real! Um dos maiores divisores de água que tive em minha carreira foi saber documentar minhas conquistas.

Seja em um documento no seu drive, seja no seu portfólio, no seu currículo...no local que for mais apropriado, escreva os impactos de seus esforços, sempre medidos com números objetivos:

✅ Reduzi o tempo de carregamento da página em 90%
❌ Melhorei o tempo de carregamento da página

A visualização objetiva dos impactos do seu trabalho pelos seus gestores e liderança direta é muito mais eficaz do que uma percepção subjetiva de que você está fazendo um bom trabalho

3. Assuma mais responsabilidade

Seja "dono" de partes do projeto. Isso não quer dizer monopolizar conhecimento sobre aquilo, mas pelo contrário, difundir o que você sabe, se tornando a referência técnica no assunto. Seja quem as pessoas procuram quando necessitam de ajuda ou direcionamento sobre aquela parte da empresa. Isso vai te colocar em uma posição essencial, raramente considerada como dispensável.

Sugiro ter conversas com seus gestor, solicite direcionamento no que você pode melhorar, e se coloque a disposição para assumir novas oportunidades de crescimento. Essa também é uma boa oportunidade de mostrar os itens que você documentou na dica anterior 😄

E ai, o que achou?
Pra galera que já passou por isso, teriam mais alertas ou dicas para adicionar?

Fala, pessoal!

Estou construindo um sistema e queria umas dicas de quem já mexeu com algo parecido.

A ideia é simples: o usuário descreve os resultados de uma campanha em texto (tipo "Gastei R$ 3.000, tive 34 vendas de R$ 450, e 210 pessoas interessadas") e a IA devolve um diagnóstico do que tá funcionando, do que não tá, e do que fazer em seguida. Tudo em linguagem de cliente, sem siglas tipo ROAS, CTR ou CAC.

A arquitetura que pensei:

• Frontend no Lovable
• Backend no Supabase com RLS e multi-tenant
• Motor de IA com três camadas: Analytics AI (insights), Opportunity Engine (recomendações) e Motor de Regras (automação)

O que já tenho funcionando:

• Área do cliente com Nova Análise, Visão Geral e Relatórios
• IA já gera insights com base nos dados inseridos
• Multi-tenant configurado

O que ainda estou desenvolvendo:

• Motor de Regras (SE/ENTÃO)
• Botão para aplicar recomendações direto na campanha
• Feedback Loop para a IA aprender com acertos e erros

Minhas dúvidas:

1. Alguém já usou IA para traduzir métricas técnicas em linguagem de cliente? Como vocês fizeram?
2. Para o Motor de Regras, vocês recomendam guardar as regras no banco ou em código?
3. Alguma dica para implementar o Feedback Loop de forma eficiente?

Qualquer ajuda é bem-vinda. Valeu! 🚀

Dei uma viajada na maionese e tentei trazer o conceito de Roda do Jeremy Evans para PHP, meus testes em Roda foram fenomenains e a curva de aprendizagem é bem baixa. Não vou me alongar em conceitos e como o Roda funciona, isos fica de lição de casa kkkk, mas usei o Grok para tentar fazer algo usável no mesmo conceito em PHP, a ideia era uma POC, testar rápido para concluir rápido, e achei bem promissor.

Chamei de Stem(tronco), a ideia não era travar no nome, só testar, então não ligue pra isso kkkkk

Link da documentação: StemPHP

A projeção elevaria o faturamento anual para cerca de 680 bilhões de dólares, ante uma estimativa de 400 bilhões para o atual ano fiscal. Huang destaca que a tecnologia da Nvidia é uma “plataforma fundamental” para a indústria de IA e está presente na maioria dos modelos desenvolvidos atualmente, incluindo os de grandes empresas como Anthropic, OpenAI e Google.

A condição é causada pela exposição repetida e prolongada a calor de baixa intensidade, provocando uma erupção com aparência semelhante a uma renda. Geralmente, é benigna e reversível quando a fonte de calor é removida. O garoto, que conseguiu reverter o quadro após meses de cuidado, faz ensino domiciliar e utiliza o aparelho para estudar.

No Reino Unido, reclamações ao ouvidor de habitação passaram de 2.600 em 2022 para mais de 7.000 em 2025, alta de aproximadamente 169%. O auxílio-doença do INSS do Brasil aparece no estudo, mas os números não foram divulgados. Segundo o pesquisador Chris Schmitz, que analisou 84 casos em 11 jurisdições diferentes, a IA reduziu a necessidade de reunir contexto, entender processos complexos e redigir textos precisos ao registrar solicitações.

Fontes:

• https://techcrunch.com/2026/09/10/ai-agents-are-flooding-public-services-with-new-requests/
• https://arxiv.org/html/2608.16603#1

A decisão coloca a tecnologia no mesmo patamar de C++, C# e TypeScript e permite que desenvolvedores da empresa optem oficialmente pela linguagem em seus projetos. Segundo Mark Russinovich, CTO do Azure, um dos principais fatores para a mudança é a segurança de memória, responsável por cerca de 70% das vulnerabilidades do Windows.

Dentro do aplicativo, o usuário poderá escolher a opção de importar credenciais de outro provedor; o Android detectará automaticamente os gerenciadores instalados no aparelho e permitirá selecionar quais itens deseja importar. Inicialmente, a novidade está disponível nos aplicativos Google Password Manager, 1Password, Bitwarden e Dashlane.

A empresa não informou por quanto tempo as inscrições ficarão suspensas nem quantas pessoas estão se cadastrando diariamente, o que daria uma dimensão da escala da demanda. O plano Pro 5x, de 100 dólares mensais, permanece disponível.

Segundo a consultoria, com a força de trabalho global estagnada ou em declínio, a disputa por profissionais qualificados deve elevar gastos com recrutamento e treinamento. A Gartner também projeta que, até 2027, 75% das empresas que priorizarem a substituição de funcionários pela IA serão superadas por concorrentes que usaram a tecnologia para modernizar e ampliar a capacidade do seu pessoal.

A CVE-2026-85706 permite que invasores não autenticados leiam arquivos arbitrários em servidores vulneráveis, enquanto a CVE-2026-87719 possibilita que invasores autenticados com acesso ao Duo Chat roubem credenciais sensíveis e configurações de instâncias do Advanced Search. As correções foram lançadas nas versões 19.3.2, 19.2.6 e 19.1 para Community e Enterprise.

Aqui vai esta à Resenha Matematica

Oi oi!

Eu sou @nyaomaru, engenheiro frontend que ultimamente ficou completamente obcecado por ramen. 😸🍜

Você já usou o DSA View View? 👀👀

https://dev.to/nyaomaru/i-built-a-tool-to-visualize-dsa-lets-learn-together-dsa-view-view--djo

O DSA View View permite entender DSA visualizando como sua implementation realmente roda.

Nos artigos anteriores, vimos problemas como:

• Two Sum
• Binary Search
• Bubble Sort
• Valid Parentheses
• Reverse Linked List
• Maximum Depth of Binary Tree
• Number of Islands
• Invert Binary Tree
• Course Schedule

Desta vez, vamos tentar mais três:

• Trapping Rain Water
• Top K Frequent Elements
• Selection Sort

Esses três problemas apresentam formas de pensar bem diferentes:

Reduzir o problema pelos dois ladosPrimeiro contar, depois organizar por frequencySelecionar repetidamente o próximo value

Mais uma vez, as implementations não são necessariamente enormes.

Mas existem vários values mudando ao mesmo tempo, e precisamos manter tudo isso na cabeça.

Então, em vez de apenas ler o final code...

Vamos ver o que realmente acontece. 👀👀

🌧️ Trapping Rain Water

Vamos começar com Trapping Rain Water.

Suponha que temos estas alturas:

[0, 1, 0, 2, 1, 0, 1, 3]

Se desenharmos como walls, fica mais ou menos assim:

              █      █       █  █   █ █   █ █-----------------0 1 0 2 1 0 1 3

A chuva cai de cima.

Parte da água escapa.

Mas parte fica presa entre walls mais altos.

Por exemplo:

      █~~~~~~~█  █~~~█~~~~~~~█-----------------

Então a pergunta é:

Quanta água pode ficar presa?

No começo, eu achei esse problema bem confuso. 😿

Porque a quantidade de água acima de uma position depende de walls que estão em outros lugares.

Então, de que informação realmente precisamos?

Quanto de água cabe acima de uma Position?

Imagine esta position:

left wall     right wall    █             █    █      x      █    █      █      █

O water level não pode ficar mais alto que o lado menor.

Então o maior nível possível é:

Math.min(leftMax, rightMax);

Depois subtraímos a altura atual.

Conceitualmente:

water = min(leftMax, rightMax) - currentHeight

Essa é a ideia básica.

Mas será que precisamos calcular os dois lados de novo para cada position?

Não.

Podemos usar two pointers.

Two Pointers

A implementation é esta:

function trap(height: number[]): number {  let left = 0;  let right = height.length - 1;  let leftMax = 0;  let rightMax = 0;  let water = 0;  while (left <= right) {    if (height[left] <= height[right]) {      if (height[left] >= leftMax) {        leftMax = height[left];      } else {        water += leftMax - height[left];      }      left++;    } else {      if (height[right] >= rightMax) {        rightMax = height[right];      } else {        water += rightMax - height[right];      }      right--;    }  }  return water;}

Existem vários values importantes:

leftrightleftMaxrightMaxwater

Esse é exatamente o tipo de code em que eu entendo cada variable individualmente...

mas começo a me perder quando todos mudam juntos. 😹

Vamos acompanhar um example menor:

[2, 0, 1, 3]

Começando pelos dois lados

No início:

left = 0right = 3[2, 0, 1, 3] ↑        ↑left    right

As alturas são:

height[left]  = 2height[right] = 3

Como:

2 <= 3

processamos o lado esquerdo.

Existe uma wall de altura 2.

Então:

leftMax = 2

Depois movemos left.

[2, 0, 1, 3]    ↑     ↑   left right

Agora podemos prender água

A altura atual é:

0

Mas já sabemos que existe uma wall de altura 2 do lado esquerdo.

E o lado direito, neste momento, é pelo menos tão alto quanto essa wall.

Então esta position pode armazenar:

leftMax - height[left]= 2

Logo:

water = 2

Movemos novamente.

[2, 0, 1, 3]       ↑  ↑      left right

Agora:

height[left] = 1leftMax = 2

Então:

2 - 1 = 1

Mais uma unidade de água.

water = 3

Eventualmente chegamos à última wall.

Done! 🎉

Por que podemos processar o lado menor?

Essa é a parte importante.

Suponha:

height[left] <= height[right]

Nesse momento, já sabemos que existe uma wall à direita pelo menos tão alta quanto a wall atual do lado esquerdo.

Então, para a current left position, o fator limitante é a melhor wall que já encontramos pela esquerda.

Por isso podemos calcular com segurança:

leftMax - height[left];

sem precisar conhecer todas as future walls.

A mesma lógica funciona do outro lado.

Se:

height[right] < height[left]

processamos o lado direito usando rightMax.

Então o algorithm vai reduzindo a área desconhecida:

L → → →     ← ← ← R

até tudo ser processado.

Complexity

Cada pointer atravessa o array apenas uma vez.

Time:  O(n)Space: O(1)

👀 Vamos View View

Esse problema é um ótimo exemplo de por que gosto de visualization.

O code possui:

leftrightleftMaxrightMaxwater

E todos eles mudam em momentos diferentes.

Quando eu leio apenas:

water += leftMax - height[left];

posso começar a perguntar:

• Por que estamos usando leftMax aqui?
• Quanto vale rightMax agora?
• Por que movemos left em vez de right?
• Quanta water já contamos?
• Qual parte do array ainda não foi processada?

😿

https://dsa-view-view.vercel.app/#s=j.eyJlIjoidHJhcHBpbmctcmFpbi13YXRlciIsImwiOiJ0eXBlc2NyaXB0IiwibSI6InZlcmlmaWNhdGlvbiIsInYiOjF9

Step-by-step, conseguimos ver a área de busca realmente diminuindo.

L         R↓         ↓[2, 0, 1, 3]    L     R    ↓     ↓[2, 0, 1, 3]       L  R       ↓  ↓[2, 0, 1, 3]

Ao mesmo tempo:

leftMaxrightMaxwater

continuam mudando.

Na prática, o algorithm está perguntando:

Qual lado eu já consigo resolver com segurança agora?

Depois resolve esse lado e anda para dentro. 🌧️😸

🔢 Top K Frequent Elements

Agora vamos encontrar os Top K Frequent Elements.

Suponha que temos:

[1, 1, 1, 2, 2, 3]

e:

k = 2

Quantas vezes cada number aparece?

1 → 3 vezes2 → 2 vezes3 → 1 vez

Então os dois values mais frequentes são:

[1, 2]

Até aqui, simples.

Mas como implementar?

Primeiro, conte tudo

A primeira coisa que precisamos é da frequency.

Podemos usar um Map.

const frequency = new Map<number, number>();

Depois contamos cada value.

for (const num of nums) {  frequency.set(num, (frequency.get(num) ?? 0) + 1);}

Para:

[1, 1, 1, 2, 2, 3]

obtemos:

frequency = {  1 → 3  2 → 2  3 → 1}

Nice.

Mas ainda precisamos do top K.

Claro, poderíamos ordenar tudo por frequency.

Mas existe outra abordagem interessante.

Use Frequency como Index

A maior frequency possível é:

nums.length

Então podemos criar buckets.

const buckets: number[][] = Array.from(  { length: nums.length + 1 },  () => []);

O próprio index representa a frequency.

Por exemplo:

bucket[1] = values que aparecem 1 vezbucket[2] = values que aparecem 2 vezesbucket[3] = values que aparecem 3 vezes

No nosso example:

frequency = {  1 → 3  2 → 2  3 → 1}

os buckets ficam:

index 0 → []index 1 → [3]index 2 → [2]index 3 → [1]

Isso é bem interessante. 👀👀

Em vez de perguntar:

Qual é a frequency deste number?

invertemos a relação:

Quais numbers possuem esta frequency?

Implementation

A implementation completa fica assim:

function topKFrequent(nums: number[], k: number): number[] {  const frequency = new Map<number, number>();  for (const num of nums) {    frequency.set(num, (frequency.get(num) ?? 0) + 1);  }  const buckets: number[][] = Array.from(    { length: nums.length + 1 },    () => []  );  for (const [num, count] of frequency) {    buckets[count].push(num);  }  const result: number[] = [];  for (let count = buckets.length - 1; count >= 0; count--) {    for (const num of buckets[count]) {      result.push(num);      if (result.length === k) {        return result;      }    }  }  return result;}

Vamos acompanhar.

Step 1: Construir o Frequency Map

Começamos com:

frequency = {}

Lemos o primeiro 1.

Depois outro.

Depois outro.

1 → 11 → 21 → 3

Depois vem 2.

E outro 2.

1 → 32 → 12 → 2

Finalmente 3.

1 → 32 → 23 → 1

Done.

Step 2: Colocar os Values nos Buckets

Agora:

buckets[count].push(num);

Para:

1 → 3

fazemos:

buckets[3].push(1)

Para:

2 → 2

fazemos:

buckets[2].push(2)

E:

3 → 1

vira:

buckets[1].push(3)

Então:

0: []1: [3]2: [2]3: [1]

Step 3: Ler da maior Frequency

Queremos os values mais frequentes.

Então não começamos do 0.

Começamos do final.

3 → [1]2 → [2]1 → [3]

Pegamos 1.

result = [1]

Ainda falta mais um.

Descemos.

Pegamos 2.

result = [1, 2]

Agora:

result.length === k

Então retornamos.

Done! 🎉

Por que isso é interessante?

Eu gosto dessa solution porque a segunda data structure muda completamente a forma como olhamos a informação.

O Map diz:

value → frequency

Os buckets dizem:

frequency → values

Mesma informação.

Direção diferente.

E, de repente, encontrar os values mais frequentes fica muito simples.

Só precisamos andar de trás para frente pelos buckets.

Complexity

Contamos cada number uma vez.

Distribuímos cada unique number em um bucket.

Depois percorremos os buckets.

Time:  O(n)Space: O(n)

👀 Vamos View View

Aqui os dados mudam de formato várias vezes.

Primeiro:

nums ↓frequency Map

Depois:

frequency Map ↓buckets

E então:

buckets ↓result

Quando lemos apenas a final implementation, pode ser fácil perder o motivo de criarmos duas data structures diferentes.

https://dsa-view-view.vercel.app/#s=j.eyJlIjoidG9wLWstZnJlcXVlbnQiLCJsIjoidHlwZXNjcmlwdCIsIm0iOiJ2ZXJpZmljYXRpb24iLCJ2IjoxfQ

Com o runtime visível, podemos acompanhar os dados mudando de forma.

[1, 1, 1, 2, 2, 3]        ↓ count1 → 32 → 23 → 1        ↓ bucket1: [3]2: [2]3: [1]        ↓ highest first[1, 2]

Essa é a parte que eu gosto.

Nós não encontramos o top K por mágica.

Reorganizamos a informação até a resposta ficar fácil de ler. 🔢😸

👉 Selection Sort

Por fim, vamos ordenar alguma coisa de novo!

Já vimos Bubble Sort em um artigo anterior.

Desta vez, vamos tentar Selection Sort.

Suponha:

[5, 3, 4, 1, 2]

Queremos:

[1, 2, 3, 4, 5]

Selection Sort segue uma ideia bem simples:

Encontre o menor value restante e mova para a frente.

Depois repita.

First Pass

Começamos:

[5, 3, 4, 1, 2] ↑ i

Assumimos que o primeiro value é, por enquanto, o menor.

minIndex = 0

Depois fazemos scan de tudo à direita.

5 vs 3

3 é menor.

Então:

minIndex = 1

Depois:

3 vs 4

Nada muda.

Depois:

3 vs 1

1 é menor.

minIndex = 3

Finalmente:

1 vs 2

Ainda é 1.

Então o menor value está no index 3.

Swap:

[5, 3, 4, 1, 2] ↑        ↑ i       min

↓

[1, 3, 4, 5, 2]

Agora a primeira position está pronta.

[1 | 3, 4, 5, 2] ↑sorted

Repeat

Agora começamos no index 1.

[1 | 3, 4, 5, 2]     ↑     i

Procuramos o menor value em:

[3, 4, 5, 2]

É 2.

Swap.

[1, 2 | 4, 5, 3]

De novo.

Encontre o menor value restante.

3

Eventualmente:

[1, 2, 3, 4, 5]

Sorted! 🎉

Implementation

function selectionSort(nums: number[]): number[] {  for (let i = 0; i < nums.length - 1; i++) {    let minIndex = i;    for (let j = i + 1; j < nums.length; j++) {      if (nums[j] < nums[minIndex]) {        minIndex = j;      }    }    if (minIndex !== i) {      [nums[i], nums[minIndex]] = [nums[minIndex], nums[i]];    }  }  return nums;}

Existem dois indexes importantes:

iminIndex

E também:

j

que procura dentro da área ainda unsorted.

Por que se chama Selection Sort?

Porque em cada pass selecionamos o menor value restante.

Encontrar o menor  ↓Selecioná-lo  ↓Mover para a frente  ↓Repetir

Esse é basicamente o algorithm inteiro.

Complexity

Para cada position, procuramos entre os values restantes.

Então:

Time: O(n²)

O array é ordenado in place.

Space: O(1)

Selection Sort não é algo que eu escolheria normalmente para ordenar um huge production dataset. 😹

Mas, como learning algorithm, ele é maravilhosamente visual.

👀 Vamos View View

A implementation tem nested loops.

for (let i = 0; i < nums.length - 1; i++) {  let minIndex = i;  for (let j = i + 1; j < nums.length; j++) {

Lendo o code, eu posso facilmente perder:

• Qual área já está sorted?
• Onde está i?
• Onde está j?
• Para onde minIndex aponta agora?
• Em que momento exatamente o swap acontece?

https://dsa-view-view.vercel.app/#s=j.eyJlIjoic2VsZWN0aW9uLXNvcnQiLCJsIjoidHlwZXNjcmlwdCIsIm0iOiJ2ZXJpZmljYXRpb24iLCJ2IjoxfQ

Quando visualizamos, o pattern básico fica óbvio.

[5, 3, 4, 1, 2]          ↑       smallest[1 | 3, 4, 5, 2]               ↑            smallest[1, 2 | 4, 5, 3]

O algorithm vai aumentando continuamente uma área finalizada da esquerda para a direita.

Isso é Selection Sort.

Escolha o menor value restante.

Coloque-o na próxima position.

E repita. 🍥😸

🧠 O que realmente aprendemos?

Novamente, esses três problemas parecem completamente diferentes.

Mas cada um apresenta uma forma útil de pensar.

Trapping Rain Water

Use informação dos dois lados para decidir qual parte já pode ser resolvida com segurança.

De qual lado eu já sei o suficiente agora?

Top K Frequent Elements

Às vezes contar os dados é apenas o primeiro passo.

Reorganize a informação em uma estrutura onde a resposta fique fácil de obter.

Posso reorganizar esta informação em torno do que realmente preciso?

Selection Sort

Construa a resposta uma position definitiva de cada vez.

Qual value deve ocupar esta position agora?

Então, desta vez vimos:

Two pointersFrequency bucketsSelection

Três mental models diferentes de novo.

E, assim como nos problemas anteriores, a parte difícil muitas vezes não é a syntax.

É o changing state.

Qual pointer se moveu?Qual é o maximum agora?O que existe dentro do Map?Qual bucket mudou?Onde está minIndex?Qual parte já está pronta?

É coisa demais para manter na cabeça.

Então, em vez disso, eu quero ver. 👀👀

🎯 Conclusão

Neste artigo, vimos:

• Trapping Rain Water com two pointers
• Top K Frequent Elements com frequency buckets
• Selection Sort

E, mais importante, acompanhamos como o state muda enquanto cada algorithm roda.

No Trapping Rain Water, vimos dois pointers avançando para dentro enquanto leftMax, rightMax e water mudavam.

left →       ← right

No Top K Frequent Elements, vimos os mesmos dados mudarem de representation.

array  ↓frequency Map  ↓buckets  ↓result

No Selection Sort, vimos a área sorted crescer uma position de cada vez.

É exatamente para ver esse tipo de coisa que criei o DSA View View.

https://dsa-view-view.vercel.app

Você pode escrever ou carregar uma TypeScript implementation, rodar com seus próprios inputs e navegar backward / forward pelo runtime.

Se você também está aprendendo DSA, experimente visualizar um desses problemas step-by-step.

E se houver algum problema de DSA que você gostaria que eu abordasse no próximo artigo, me conta nos comentários!

Eu ainda tenho muitos algorithms para aprender também. 😸

Vamos treinar nossos músculos de DSA juntos! 💪

Se você gostar do DSA View View, deixe uma star ⭐

https://github.com/nyaomaru/dsa-view-view

Até o próximo artigo!

Um processo Node.js que reinicia sozinho a cada 40 minutos raramente está com bug de lógica. Está com vazamento de memória.

O sintoma clássico: o container roda liso por meia hora, o heap_size_used sobe em degraus, o garbage collector começa a rodar com mais frequência (major GC a cada poucos segundos em vez de a cada poucos minutos), a latência p99 dobra e o orquestrador mata o pod com OOMKilled. Reiniciar resolve. Por 40 minutos.

Este post é sobre encontrar a causa, não sobre aumentar --max-old-space-size.

Como o V8 decide o que é lixo

Existe um mito persistente de que o garbage collector do JavaScript usa contagem de referências. Não usa, e essa confusão faz gente escrever código defensivo inútil.

O V8 usa mark-and-sweep com alcançabilidade a partir de um conjunto de raízes (GC roots): o objeto global, a pilha de execução atual, closures ativas, e no browser, a árvore do DOM viva. Tudo que não é alcançável a partir dessas raízes vira lixo, independentemente de quantas referências circulares exista entre os objetos.

// Isto NÃO vaza. Ciclo é irrelevante para mark-and-sweep.function criarCicloIsolado() {  const pedido = { id: 1 };  const cliente = { nome: 'Ana' };  pedido.cliente = cliente;  cliente.ultimoPedido = pedido; // referência circular  return null; // ninguém mais alcança pedido nem cliente}criarCicloIsolado();// Ambos são coletados no próximo major GC.

O heap do V8 é dividido em gerações. Objetos novos nascem na new space (Scavenger, coleta rápida e frequente, tipicamente 1-16 MB). Objetos que sobrevivem a duas coletas são promovidos para a old space, varrida pelo Mark-Compact, que é caro. Um vazamento é, quase sempre, objetos sendo promovidos para old space e nunca liberados de lá.

Isso importa na prática: se seu vazamento envolve objetos grandes e de vida curta, você não tem vazamento, tem pressão de alocação (aumenta o custo de GC mas o heap estabiliza). Se o heapUsed após um major GC forçado continua subindo, aí sim é vazamento.

// medir-heap.js — rode com: node --expose-gc medir-heap.js// --expose-gc é a única forma confiável de medir heap "limpo" sem// confundir lixo pendente com vazamento real.function heapDepoisDoGC() {  global.gc(); // força major GC síncrono  const { heapUsed, external, arrayBuffers } = process.memoryUsage();  return {    heapMB: (heapUsed / 1024 / 1024).toFixed(2),    externalMB: (external / 1024 / 1024).toFixed(2),    arrayBuffersMB: (arrayBuffers / 1024 / 1024).toFixed(2),  };}setInterval(() => {  console.log(new Date().toISOString(), heapDepoisDoGC());}, 10_000);

Se heapMB sobe monotonicamente ao longo de 20 amostras sob carga constante, você tem vazamento no heap JavaScript. Se heapMB fica estável mas o RSS do processo sobe, o vazamento está fora do heap do V8: Buffers, addons nativos, ou fragmentação do alocador.

Essa distinção entre linguagem e runtime é a mesma que aparece quando se discute o modelo de execução do JavaScript: a especificação da linguagem não diz nada sobre GC gerational nem sobre libuv. Tudo isso é V8 e Node.js.

As cinco causas que respondem por quase todo vazamento real

1. Listeners que nunca são removidos

O caso mais comum em Node.js e o mais comum em SPAs. Cada addEventListener ou .on() cria uma referência forte do emissor para o handler, e do handler para tudo que ele captura no escopo.

Este é um trecho. O tutorial completo, com todos os exemplos, os testes e as limitações, está em https://www.vivodecodigo.com.br/backend/memory-leaks-javascript-diagnostico-heap-snapshot-producao. Se você já passou por esse problema de outro jeito, conta nos comentários: a discussão aqui ajuda a melhorar o artigo.

Sobre os números deste texto. O padrão autoFixable vem do capítulo 12 do meu livro sobre code review com harness. Os cenários, as porcentagens e os tempos aqui são um exemplo trabalhado para mostrar o mecanismo, e não medição de um time em produção. Meça no seu repositório antes de adotar qualquer número daqui.

A bolha da IA em code review vende uma narrativa simples: "conecte CodeRabbit / GitHub Copilot Reviewer / seu agente favorito no PR, e ele revisa tudo". O que essa narrativa esconde é a proporção: uma fatia grande dos comentários da IA, na casa de 40%, é sobre coisa que o linter arruma sozinho, antes do agente gastar 1 token sequer.

A IA está certa nesses 40%. A qualidade dela não estava em jogo. Simplesmente aquele serviço cabia ao ruff --fix, resolvido em 2 segundos por 0 centavos.

Isolando o "mecânico" do "julgamento" e colocando o linter na frente da IA, o tempo de PR (abertura até merge) cai para algo em torno de 40% do que era, e a conta da API de review desce junto, porque o agente para de ler diff que não precisava.

O erro conceitual: tratar IA como a única camada de review

O discurso padrão da comunidade é "review humano é caro, então joga IA em cima". O problema é que isso pula uma etapa. Existem 3 camadas de review, e o custo por comentário muda muito entre elas:

Rodar tudo pela camada 2 é o mesmo erro que rodar tudo pela camada 3 há 5 anos. A gente ri hoje de "cada bug de vírgula vira comentário de review humano", mas agora paga a mesma piada pra IA. Só que em dólar.

O padrão autoFixable é isto: marque com um rótulo (label / tag / atributo) tudo que o linter pode resolver, e não deixe passar pra camada 2.

O que conta como autoFixable em 2026

O ecossistema mudou muito rápido. Números atuais dos linters que uso:

• Biome 2.x (JS/TS/JSX): 200+ regras nativas, sendo a maioria autofixable. Substitui ESLint + Prettier num binário Rust
• ESLint (legacy JS/TS): ainda tem o maior ecossistema, cerca de 300+ regras core + centenas de plugins, mas Biome já cobre ~80% dos casos comuns
• Ruff 0.11+ (Python): 900+ regras, com um selo de martelo indicando as autofixable (a maioria). Já substituiu flake8 + isort + black + pylint em vários projetos no último ano

Se você programa em JS/TS ou Python e não tem biome check --write ou ruff check --fix num pre-commit hook, você já está pagando comentário humano/IA por coisa que era pra ter sumido antes do PR abrir.

Meu fluxo: 2 gates antes da IA ver o diff

Gate 1: pre-commit hook (local, ~2s). Roda biome check --write (ou ruff check --fix no repo Python). Se o dev commitar sem rodar, o hook roda por ele. 90% das correções mecânicas somem aqui.

Gate 2: GitHub Action no push (~15s). Mesma coisa, mas garantida no servidor. Se sobrou algo, um bot commita direto no branch do PR com chore: auto-fix format and lint. Só depois disso o job de review de IA é acionado.

O trecho do Gate 2 em .github/workflows/autofix.yml:

name: autoFixable gateon:  pull_request:    types: [opened, synchronize]jobs:  autofix:    runs-on: ubuntu-latest    permissions:      contents: write    steps:      - uses: actions/checkout@v4        with:          ref: ${{ github.head_ref }}          token: ${{ secrets.GITHUB_TOKEN }}      - uses: actions/setup-node@v4        with: { node-version: '22' }      - run: npx --yes @biomejs/biome check --write .      - name: Commit autoFixable changes        run: |          git config user.name "autofixable-bot"          git config user.email "autofixable-bot@users.noreply.github.com"          git diff --quiet || (            git add -A &&            git commit -m "chore: autoFixable — biome check --write" &&            git push          )  ai-review:    needs: autofix    runs-on: ubuntu-latest    steps:      - run: echo "só roda depois que o autofix limpou tudo"

O detalhe importante: needs: autofix. Sem isso, o agente vê o diff sujo e comenta sobre coisa que já ia sumir 8 segundos depois. Já rodei os dois em paralelo por engano e a IA fez 12 comentários de import não usado no mesmo PR, todos autoFixable. Prejuízo em tokens, ruído no PR, dev irritado.

Os números reais de 3 meses

Vale comparar duas janelas equivalentes do mesmo projeto (por exemplo Next.js + FastAPI), uma com a camada de autofix e outra sem:

O ponto que me deixou pensativo: comentário humano caiu bem menos que o de IA (-10% vs -41%). Faz sentido. O humano já ignorava a maior parte das picuinhas de formatação, foca em julgamento, é caro. A IA é barata e desatenta, então enche linguiça.

Se a sua chefia está considerando "colocar CodeRabbit em todo PR pra ver se ajuda", mostre esse número. O ganho vem de deixar a IA fora do que o linter já resolveu. Ler mais diff só sobe a conta.

A parte polêmica que TabNews vai discutir

Vou dizer o que pouca gente escreve: estão aplicando review de IA no problema errado. Apontar no-unused-vars é serviço de compilador. O que rende para a IA é o espaço entre o linter (rígido demais pra entender contexto) e o humano (caro demais pra tudo): coisas como "esse endpoint quebra o contrato do arquivo X que você não abriu", "esse nome é enganoso porque no domínio da sua equipe X significa Y".

Quando você faz o linter comer os 41%, sobra pra IA justamente o trabalho onde ela ganha do linter. E aí cada dólar gasto rende mais.

Já escrevi sobre revisão de código IA passo a passo sem IA com tree-sitter, onde o argumento é parente: existem passos de análise estática que resolvem parte do que se atribui hoje à IA. Junte os dois posts e você tem o modelo mental completo: linter primeiro, análise sintática segundo, IA por último, humano só no julgamento.

Para quem quer o benchmark cross-agent de qual IA usar depois que o linter já tirou o lixo, escrevi em inglês o ChatGPT Codex vs Claude Code: 47 PRs Benchmarked. O custo de 3,4x entre os dois é mais preocupante quando você tá pagando pra ele ler diff mecânico.

Resumo

• 41% dos comentários que a IA fazia no meu PR eram autoFixable pelo linter, trabalho de US$0 sendo pago em tokens
• Gate duplo (pre-commit + GitHub Action) tira o mecânico antes do review de IA acontecer
• Tempo de PR caiu 47min → 19min, custo da API de review caiu 41%, comentário humano quase não mudou
• O objetivo é reservar a IA para os problemas que ficam além do compilador. Menos diff pra IA ler = mais qualidade por dólar gasto.

ken imoto · WebRTC & Voice AI engineer · kenimoto.dev · TabNews

Um agente implementa a correção, outro revisa e um terceiro abre o app no navegador para percorrer o fluxo afetado. Parece uma automação bem organizada, até alguém perguntar qual commit passou por cada etapa.

O implementador escreveu "concluído" no chat e publicou uma branch. Enquanto o revisor lia o resumo, entrou mais um commit. O agente de QA abriu a branch que já estava no ambiente e encontrou tudo verde. No fim, implementação, revisão e teste podem ter usado três versões diferentes do código.

Nenhum prompt resolve essa confusão sozinho. O prompt explica o que uma etapa deve fazer; o protocolo entre etapas registra o artefato recebido, o resultado produzido e a condição que permite avançar.

Quando colocamos o segundo agente no fluxo, uma tarefa vira um pipeline e estado explícito deixa de ser detalhe de infraestrutura.

O segundo agente muda a natureza do trabalho

Uma execução isolada pode receber contexto, alterar arquivos e devolver uma resposta. Se ela falhar, uma pessoa olha o resultado e decide o que fazer. Já uma cadeia com implementação, revisão e QA precisa coordenar espera, trabalho parcial, interrupção e retomada sem depender de alguém reinterpretar a conversa inteira.

O Cobalt 1.0 tornou esse desenho bem visível ao separar tarefas de implementação, revisão independente e testes no navegador. Cada tarefa mantém seu ambiente e histórico, enquanto o handoff de código usa branch, commit ou pull request. Os workers publicam resultados, inclusive falhas, e o fluxo pode parar em pontos definidos para uma decisão humana.

Não é necessário adotar essa ferramenta para aproveitar a ideia. Um time pequeno consegue aplicar o mesmo princípio em um script, uma GitHub Action ou um serviço interno. A regra é simples: uma etapa só começa quando consegue localizar e validar a saída exata da etapa anterior.

"O revisor recebeu a mensagem" não é uma condição de transição. "O revisor recebeu o commit c94bd17, derivado da base 8f31c2a, com testes unitários e typecheck aprovados" já pode ser verificado.

Estado precisa comandar comportamento

O painel pode exibir vinte etiquetas e ainda assim não ter uma máquina de estados. Os nomes só ajudam quando cada um impõe regras ao runtime.

Eu começaria com poucos estados:

As transições recusadas mostram se esses estados governam o processo. failed não pode escorregar para o QA porque algum campo do painel ficou verde. approved sem um hash deixa de ser aprovação e vira opinião. Se aparecer um commit novo, a revisão anterior continua registrada, mas não vale para a nova referência.

Também vale separar estágio de estado. review é uma fase do fluxo; running, blocked e approved descrevem a situação de uma tentativa naquela fase. Misturar os dois conceitos cria combinações difíceis de operar, como um genérico review_done que não informa se houve aprovação, reprovação ou interrupção.

O handoff mínimo cabe em um arquivo pequeno

Não passe a transcrição do chat para o próximo agente e espere que ele descubra o que importa. Passe um registro curto, estruturado e apontando para os artefatos completos.

task_id: checkout-form-42attempt: 2stage: implementstatus: ready_for_reviewinput_ref: 8f31c2aoutput_ref: c94bd17checks:  - name: unit    result: passed  - name: typecheck    result: passedblocked_by: nullnext_allowed: review

Esse YAML não torna o processo confiável por conta própria. O próximo worker precisa rejeitar o handoff quando falta uma referência, quando o estado não permite a etapa pedida ou quando um check obrigatório não aparece. O coordenador também precisa impedir duas execuções com o mesmo task_id e attempt.

O registro pode incluir horário, executor, riscos restantes e um endereço para logs detalhados. Evite colocar secrets, tokens ou a conversa completa ali. Handoff é uma interface entre etapas, não um depósito para tudo o que aconteceu na sessão.

O revisor deve validar o endereço antes do código

Ao receber output_ref: c94bd17, o revisor busca esse commit e confirma que ele deriva da base esperada. Só depois abre o diff e roda os checks próprios da revisão. Se a branch avançar durante o processo, nada muda na referência já recebida.

Uma aprovação também deve carregar o commit revisado. O browser QA consome esse hash, prepara o app a partir dele e registra qual jornada executou. "Testei a branch" é ambíguo demais para servir de evidência porque branches se movem.

Esse cuidado evita uma falha comum em automações rápidas: cada agente faz seu trabalho corretamente sobre uma entrada diferente. O resultado local de cada etapa parece bom, mas a cadeia nunca validou um artefato único de ponta a ponta.

Um commit novo depois da revisão abre uma nova tentativa ou devolve o fluxo à fila. Não há motivo para apagar a aprovação anterior; ela continua útil para auditoria. O sistema apenas deixa de tratá-la como autorização para o código mais recente.

Cada tipo de falha pede uma resposta diferente

Retry automático é ótimo para uma queda transitória de rede e péssimo para uma operação que pode ter produzido efeito parcial. Antes de repetir, o coordenador precisa saber qual limite venceu, se o worker chegou a agir e se a operação tolera duplicidade.

O changelog do Cline SDK traz um caso concreto. Na versão 0.0.82, foi corrigida uma situação em que o timeout de 60 segundos de um servidor inacessível ultrapassava o teto de 30 segundos do hub e derrubava a sessão. Em uma cadeia, manda o menor orçamento de tempo. A etapa interna não pode prometer que esperará mais do que seu chamador suporta.

As classes de falha pedem respostas diferentes:

• blocked espera uma permissão, dependência ou decisão humana;
• um check reprovado volta ao implementador com o achado e a referência testada;
• um timeout anterior ao início pode permitir nova tentativa;
• um timeout com efeito desconhecido exige consulta ao recibo da operação ou uma chave de idempotência antes de repetir;
• uma entrada obsoleta invalida a tentativa e recomeça a partir da referência atual.

O teto de tentativas também deve ser explícito. Repetir cinco vezes o mesmo bloqueio não aumenta a chance de sucesso; só adia a pessoa que precisa decidir. Quando a mesma classe reaparece, o fluxo deve parar, chamar alguém e preservar o que já foi produzido.

Interrupção e retomada merecem o mesmo cuidado. A versão 0.0.72 do Cline SDK passou a preservar prompts enfileirados durante interrupções e a tornar a parada consistente entre hosts. Preservar a fila, porém, não autoriza reexecutar cegamente. Cada item retomado ainda precisa confirmar se o campo input_ref continua válido.

Log durável precisa ter limite e propósito

Uma máquina de estados sem histórico ajuda pouco quando algo trava às três da manhã. Cada transição deveria deixar um evento com task_id, tentativa, estado anterior, novo estado, ator, referências e horário. O evento responde o que avançou e por quê; detalhes extensos podem ficar em um artefato separado, com acesso e retenção próprios.

Retenção infinita parece cômoda até snapshots, saídas de ferramentas e mensagens começarem a se acumular. O Cline SDK limitou seu event log durável a 64 MiB na versão 0.0.79 depois de snapshots completos crescerem muito mais. Copiar esse número para qualquer runtime não faria sentido. Vale definir limite, compactação e descarte antes de depender do log para retomar sessões.

Um log gigantesco também aumenta a chance de guardar segredos e dados desnecessários. Para operação diária, um recibo pequeno costuma bastar. Quando a etapa falha, ele aponta para os detalhes protegidos em vez de copiá-los para todos os agentes seguintes.

Validação integrada ajuda, mas não decide sozinha

O Xcode 27 aproxima o agente de testes, experimentos em Playgrounds, previews e interação com simuladores pelo Device Hub. Esse tipo de integração encurta o ciclo entre mudar e observar. Também aumenta a importância de registrar qual build e qual estado do ambiente produziram a observação.

O agente que implementa pode rodar testes e encontrar boa parte dos próprios erros. Ainda assim, ele pode testar a mesma suposição errada que orientou a mudança. Para uma correção visual pequena, talvez o custo de uma revisão independente não compense. Em autenticação, cobrança ou migração de dados, separar produção e aprovação costuma ser um custo bem mais fácil de defender.

A decisão pode variar conforme o impacto. O contrato não precisa obrigar três agentes em todo PR; precisa deixar claro quando a checagem do próprio agente encerra a etapa e quando outra identidade deve revisar o mesmo commit.

Um piloto que cabe no próximo PR

Escolha uma correção pequena de frontend e salve o estado em um arquivo versionado ou registro durável. Rode a sequência implement → review → browser_qa → human_merge uma vez antes de adicionar paralelismo ou mais papéis.

Durante o piloto, force situações que o happy path esconderia:

• faça um teste reprovar e confirme que o fluxo volta à implementação;
• provoque um timeout e verifique se a tentativa seguinte consegue distinguir "não começou" de "resultado desconhecido";
• adicione um commit depois da aprovação e confirme que revisão e QA antigos deixam de autorizar o merge;
• remova uma permissão e veja se o estado termina em blocked, sem uma sequência inútil de retries.

No fim, tente responder sem abrir o chat:

• qual commit cada etapa recebeu e qual devolveu?
• quais checks rodaram sobre cada referência?
• por que o fluxo avançou, parou ou voltou?
• quem pode liberar a próxima transição?

Se essas respostas estiverem no registro, o time já tem uma base útil. Depois vale medir quantas reexecuções foram evitadas, quanto tempo os bloqueios ficaram sem dono e quais eventos realmente ajudaram na investigação. A máquina de estados pode crescer quando surgir um caso operacional que justifique o novo estado.

Automatizar vários agentes sem esse contrato produz uma conversa movimentada e um histórico difícil de retomar. Comece com referências imutáveis, meia dúzia de estados e transições que o runtime saiba negar. Quando uma etapa falhar pela metade, o time poderá localizar o último commit válido, entender por que o fluxo parou e retomar sem reler a conversa.

Fontes

• Cobalt 1.0
• Cline SDK changelog
• Apple: Xcode 27 e novas ferramentas de inteligência

Olá! Sou estudante do ensino médio e queria explorar a área de desenvolvimento web, então criei meu primeiro projeto: MateBásica (https://matebasica.com.br). Ele começou de forma despretensiosa, apenas como um passatempo nas minhas últimas férias, mas no meio do processo enxerguei um potencial real de criar um auxílio acadêmico nacional, além de enxergar oportunidades pessoais na área de tecnologia.

Dediquei dezenas de horas desenvolvendo tudo individualmente, usando apenas recursos gratuitos. Criei a estrutura, o design, as funcionalidades principais, o ícone e comprei o domínio. Hoje, com um mês e meio de vida/maturação do site, quero compartilhar os bastidores de como ergui esse projeto e os desafios técnicos e operacionais que enfrentei.

Inteligência Artificial e a ilusão do "trabalho automatizado"

Usei IA para gerar partes dos textos e alguns elementos do site, mas quem acha que isso automatiza o projeto inteiro está bem enganado. A curadoria, organização, gestão, vínculos e a administração de todo o sistema foi um trabalho hercúleo. Cadastrar e revisar centenas de questões, artigos e formatar o banco de dados no meu próprio computador exigiu um esforço operacional árduo para garantir que o conteúdo realmente tivesse valor para um vestibulando.

A Stack e outros desafios

Na tentativa de manter o custo zero no início, utilizei o Cloudflare Pages para a hospedagem. É uma plataforma excelente, mas a construção do front-end trouxe desafios que me deram bastante problema:

• Conflitos de Renderização Matemática: A plataforma é focada em matemática, o que exige renderizar fórmulas complexas na tela. Integrar LaTeX/KaTeX com o HTML gerou diversos conflitos de formatação e quebras de layout que precisei consertar manualmente.

• Mudança entre modelos de aplicação: Tive dificuldades estruturais para controlar estados e fazer a transição fluida entre diferentes páginas e componentes sem prejudicar/quebrar as funcionalidades, especialmente no gerador de PDFs e na interface de simulados.

O momento atual

O site tem 51 dias no ar (no momento em que escrevo). O ecossistema está funcional, mas agora enfrento a fase mais difícil de qualquer projeto indie: a distribuição e a divulgação. Estou buscando expandir o acesso para validar a ferramenta com um público maior. O objetivo final é conseguir apoio e, possivelmente, algum retorno que viabilize e incentive a continuação do desenvolvimento, mantendo o ambiente limpo e gratuito para os estudantes.

Gostaria de convidar a comunidade do TabNews para testar a plataforma da forma como preferirem. Se a análise for técnica, deixo alguns questionamentos: Como está a performance do carregamento e a renderização do KaTeX nos diferentes navegadores que vocês usam? Encontraram algum gargalo/problema de usabilidade na geração dos PDFs (cuja variação para cada dispositivo e navegador tem me desafiado muito) ou na navegação dos simulados? Quais estratégias de distribuição inicial vocês recomendariam para um projeto focado em educação feito por um desenvolvedor solo?

Qualquer crítica honesta sobre a aparência do código, a UX ou a infraestrutura será recebida como aprendizado. Se gostarem e simplesmente quiserem usar e compartilhar, fico igualmente grato. Apesar de uma postagem com intuito descritivo e também de dúvidas, deixo aqui esse gancho para a divulgação e utilização do MateBásica! Obrigado pela leitura.

SEO técnico não morreu com a chegada da IA. Ele se tornou o filtro de entrada para qualquer disputa por visibilidade orgânica.

A maioria dos artigos sobre o tema erra ao tratar SEO técnico e conteúdo como estratégias separadas que competem entre si. Na prática, uma é pré-requisito da outra.

O que mudou de verdade

A inteligência artificial mudou como o Google apresenta resultados. Os AI Overviews dominam o topo da SERP, a busca conversacional retém o usuário dentro do próprio Google e o conceito de "primeira posição" perdeu parte do significado que tinha.

Mas nada disso dispensou os fundamentos técnicos. O que mudou foi o custo de ignorá-los.

Se o Googlebot não consegue rastrear, indexar e interpretar o seu site com clareza, a IA do Google não vai citá-lo como fonte. E sem ser citado nos AI Overviews, o site fica invisível para uma fatia crescente das buscas informacionais, que já superam 40% do volume total de consultas respondidas diretamente na SERP.

Duas camadas de competição simultâneas

Agora existem duas disputas acontecendo ao mesmo tempo:

1. A tradicional: aparecer nos resultados orgânicos com boa posição
2. A nova: ser selecionado como fonte confiável para compor os resumos gerados por IA

Para passar pelas duas, a base técnica precisa estar resolvida.

A própria Ahrefs, em um estudo com 331 mil páginas analisadas, concluiu que o Google não pune conteúdos gerados por IA. O que realmente impacta o desempenho é a qualidade do conteúdo. Mas esse julgamento de qualidade pressupõe que o conteúdo foi rastreado e interpretado corretamente. Se a infraestrutura técnica falha antes disso, o julgamento nunca acontece.

O que mudou nos fatores técnicos específicos

Dados estruturados deixaram de ser recomendação e viraram requisito

Schema Markup sempre foi recomendado como boa prática. Em um cenário dominado por IA generativa, ele passou a funcionar como um guia de leitura que a IA usa para entender o tipo, o contexto e a relevância do conteúdo antes de decidir se vai citá-lo.

Uma página com Schema de FAQ implementado corretamente sinaliza para a IA que aquele bloco foi estruturado para responder perguntas específicas. Uma página sem nenhum markup deixa a IA inferindo tudo a partir do texto bruto, reduzindo a precisão da interpretação e a probabilidade de citação.

Os schemas mais relevantes para aumentar a chance de citação nos AI Overviews: FAQ, HowTo, Article, Review, BreadcrumbList, Product e Event.

Arquitetura de informação dentro da página ganhou peso técnico

Esse ponto raramente aparece nas listas de SEO técnico, mas passou a ter impacto direto na era dos AI Overviews.

Parágrafos que respondem a uma pergunta de forma autossuficiente em 40 a 60 palavras têm estrutura ideal para extração pela IA. Headings em H2 e H3 que funcionam como perguntas reais que o usuário faria criam pontos de ancoragem que o sistema usa para selecionar trechos relevantes.

Isso não é apenas decisão editorial. É uma decisão técnica sobre como o HTML da página está organizado e como o fluxo de informação está sendo comunicado ao parser do Googlebot.

Rastreabilidade e crawl budget ficaram mais críticos

Com a IA generativa precisando processar e atualizar fontes com mais frequência, o Google precisa rastrear sites com maior regularidade. Sites com arquitetura confusa, links quebrados, redirecionamentos em cadeia ou páginas duplicadas sem canonical consomem crawl budget desnecessariamente e atrasam o processamento das páginas estratégicas.

O que o Google continua exigindo sem mudança

Alguns fundamentos são estruturalmente imunes às mudanças trazidas pela IA:

Core Web Vitals — LCP abaixo de 2,5 segundos, CLS abaixo de 0,1 e FID abaixo de 100ms continuam sendo métricas de ranqueamento ativas.

Mobile-First Indexing — conteúdo que aparece completo no desktop mas está truncado ou inacessível no mobile pode não ser indexado corretamente.

HTTPS e integridade do ambiente — a IA do Google tende a evitar citar fontes com histórico de problemas de segurança.

Canonical tags — páginas duplicadas sem canonical correto dividem autoridade e criam ambiguidade para o Googlebot.

Sitemap XML e Robots.txt — erros aqui têm consequências que se propagam por toda a indexação do site.

A intersecção entre técnico e conteúdo citável

O erro mais comum em estratégias de SEO é tratar técnico e conteúdo como silos separados. Em um cenário dominado por AI Overviews, essa separação é insustentável.

Um artigo tecnicamente perfeito com conteúdo genérico não vai ser citado. Um artigo com conteúdo original e profundo em um site com problemas técnicos também não vai ser citado. Os dois precisam estar resolvidos ao mesmo tempo.

Sites que combinam infraestrutura técnica sólida com conteúdo estruturado de forma citável estão capturando espaço que concorrentes com apenas uma das duas partes funcionando estão deixando vago.

Por onde começar

O ponto de partida é o Google Search Console. Os relatórios de cobertura, Core Web Vitals e dados estruturados já entregam um diagnóstico inicial sem nenhuma ferramenta adicional. A partir dali, Screaming Frog, Ahrefs e PageSpeed Insights aprofundam a análise nas camadas que o Search Console não cobre com granularidade suficiente.

A auditoria sozinha não resolve nada. O que gera resultado é a priorização e a execução das correções certas na ordem certa: primeiro os problemas que mais impactam rastreamento e indexação, depois performance, depois dados estruturados.

Artigo publicado originalmente em user.dev.br

Página do App na Microsoft Store: CtrlAltRemapper (Microsoft Store)

Se você alterna frequentemente entre o macOS e o Windows no seu dia a dia, com certeza já passou por essa "dor". No MacBook em casa você usa o Cmd, mas no trabalho senta em frente a um PC com Windows (ou vice-versa) — e a sua memória muscular entra em colapso total. Ao tentar copiar um texto, o polegar vai automaticamente para a tecla Alt (que no teclado do PC fica na mesma posição física do Cmd no Mac), e o resultado é o menu do aplicativo sendo ativado ou nenhuma resposta...

Tentei algumas ferramentas de remapeamento existentes, mas nenhuma me satisfez. Ou a variedade de atalhos era extremamente limitada, ou exigia configurações manuais e tediosas para cada atalho.

Objetivos do Projeto

Eu queria resolver esse problema com um aplicativo leve e sem interface gráfica (GUI). O objetivo era um simples "execute uma vez e esqueça", sem necessidade de ajustes constantes.

• Sem GUI pesada: O aplicativo roda silenciosamente na bandeja do sistema (System Tray).
• Consumo mínimo de recursos do sistema.
• Privacidade total: Funciona 100% local e offline, sem coletar ou enviar digitações.
• Integração nativa com Windows 10 / 11: Formato de pacote MSIX com suporte à inicialização automática junto com o sistema.

E assim nasceu o projeto CtrlAltRemapper.

Etapa de Compilação: Da arquitetura x86 para x64 nativo

O código do remapeador foi escrito em AutoHotkey. Para converter o script em um executável standalone (.exe), utilizei o compilador padrão Ahk2Exe.

A primeira compilação foi simples. Inicialmente, optei por compilar em 32-bit (x86) pensando na compatibilidade. Porém, durante os testes, descobri que essa escolha gerava problemas no Windows 11 de 64 bits: executar hooks de teclado de 32 bits dentro de aplicativos nativos de 64 bits (como o novo Bloco de Notas) gerava uma micro-latência por causa do marshalling na camada WoW64. O Windows interpretava esse atraso mínimo como um travamento e desativava o hook global.

Após identificar a causa, recompilai o aplicativo para a arquitetura nativa x64, o que resolveu completamente o problema de desempenho dos hooks.

Tabela de Atalhos Suportados

O aplicativo traz a lógica e o layout de teclas da Apple para o ecossistema do Windows. Confira a lista completa de atalhos remapeados:

Vale destacar que o comportamento nativo da tecla Ctrl permanece 100% intocado, permitindo usar ambos os estilos de atalho em paralelo.

Automação de Build MSIX via GitHub Actions

Gerar o formato moderno de pacote do Windows (MSIX) pode ser desafiador, especialmente ao criar pipelines de CI/CD automatizados. Estruturei o pipeline criando dois workflows independentes no GitHub Actions:

1. Workflow de Produção (build.yml): Empacota o executável e recursos em um pacote .msix limpo e não assinado. Ele é enviado diretamente ao Microsoft Partner Center e assinado automaticamente com o certificado oficial e confiável da loja durante a publicação.
2. Workflow de Teste (test-sign.yml): Criado para testes locais. O script gera um certificado autoassinado em tempo de execução, exporta em formato .pfx e assina o pacote de teste usando a ferramenta signtool.exe.

Abaixo está o arquivo de configuração YAML do robot de teste, projetado para localizar dinamicamente as ferramentas do Windows SDK no runner do GitHub:

name: Test-Sign MSIX Packageon:  workflow_dispatch:jobs:  pack-and-sign:    runs-on: windows-latest    steps:    - name: Checkout code      uses: actions/checkout@v4    - name: Find Windows SDK Tools      shell: pwsh      id: tools      run: |        $makeappx = Get-ChildItem -Path "C:\Program Files (x86)\Windows Kits\10\bin" -Filter "makeappx.exe" -Recurse | Where-Object { $_.FullName -like "*x64*" } | Select-Object -First 1 -ExpandProperty FullName        $signtool = Get-ChildItem -Path "C:\Program Files (x86)\Windows Kits\10\bin" -Filter "signtool.exe" -Recurse | Where-Object { $_.FullName -like "*x64*" } | Select-Object -First 1 -ExpandProperty FullName        echo "MAKEAPPX_PATH=$makeappx" >> $env:GITHUB_ENV        echo "SIGNTOOL_PATH=$signtool" >> $env:GITHUB_ENV    - name: Pack MSIX      shell: pwsh      run: |        & "$env:MAKEAPPX_PATH" pack /d . /p CtrlAltRemapper_unsigned.msix /v    - name: Create Test Certificate and Sign      shell: pwsh      run: |        $password = ConvertTo-SecureString "TestPassword123" -AsPlainText -Force        $cert = New-SelfSignedCertificate -Type Custom -Subject "CN=BD6FFC77-0FDF-42B7-95A8-73C66D341EDE" -KeyUsage DigitalSignature -FriendlyName "TestCert" -CertStoreLocation "Cert:\CurrentUser\My" -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3")        Export-PfxCertificate -Cert $cert -FilePath "testcert.pfx" -Password $password        & "$env:SIGNTOOL_PATH" sign /fd SHA256 /a /f "testcert.pfx" /p "TestPassword123" CtrlAltRemapper_unsigned.msix        Move-Item -Path CtrlAltRemapper_unsigned.msix -Destination CtrlAltRemapper_Signed.msix    - name: Upload Signed MSIX and Certificate      uses: actions/upload-artifact@v4      with:        name: CtrlAltRemapper-TestSign-Package        path: |          CtrlAltRemapper_Signed.msix          testcert.pfx

Desafios na Certificação da Microsoft Store

Publicar um remapeador de teclas que opera em nível de sistema na Microsoft Store exigiu superar várias restrições rígidas de segurança do Windows 10/11.

1. Declaração de runFullTrust

Como o app intercepta atalhos usando a API Win32 de baixo nível (SetWindowsHookEx), a sandbox padrão do UWP bloqueava a execução. Foi necessário declarar a capacidade restrita runFullTrust no AppxManifest.xml. Durante o envio, fornecemos uma justificativa técnica detalhada sobre a segurança da utilidade e a necessidade do acesso.

2. Exigência de HeadlessAppBypass e suporte da Microsoft

No primeiro envio, enfrentamos uma rejeição automática. Como o app roda apenas na bandeja do sistema sem uma janela principal de GUI, o Windows SDK o identificou como um "headless app". As políticas da Microsoft exigiam vincular a permissão HeadlessAppBypass ao nosso Store ID.

Após contato com a equipe de suporte do Microsoft Partner Center explicando a natureza do app, o acesso foi liberado manualmente para a conta de desenvolvedor.

3. Depuração no ambiente de certificação (Erro de VCRUNTIME140.dll e máscaras de Alt)

Nos testes automatizados em ambiente limpo da Microsoft, o app apresentou falhas devido à ausência da DLL do sistema VCRUNTIME140.dll.
Para resolver as pendências de certificação:

• Recompilamos e ajustamos o manifesto para a arquitetura x64 nativa (ProcessorArchitecture="x64").
• Adicionamos a nota sobre requisitos de sistema nos listings da loja em 8 idiomas.
• Implementamos uma máscara ativa (vkFF/vkE8) para a tecla Alt, evitando que o Windows transferisse o foco para a barra de menus ao alternar atalhos rapidamente.

Considerações Finais

O desenvolvimento do CtrlAltRemapper provou que é possível levar um projeto indie focado em produtividade a um pacote de nível enterprise na Microsoft Store.

O aplicativo está disponível gratuitamente para testes no link abaixo:

Download na Microsoft Store: CtrlAltRemapper (Microsoft Store)

Feedbacks, relatos de bugs e sugestões de novos atalhos são muito bem-vindos nos comentários!

#Engenharia de Software #Produtividade #Windows #MacOS

A Shopify usa o React Native desde 2020, e muita coisa mudou desde então. Conforme a declaração no blog deles: "agentes de codificação mudaram o custo de desenvolvimento de aplicativos móveis em dobro", e resolveram sair do React Native para usar diretamente Swift e Kotlin.

O post tem vários detalhes, e a declaração acima não foi uma surpresa pra mim (na verdade é óbvio, já vimos outros casos como o Bun reescrito em Rust), mas tem algumas coisas que chamaram minha atenção, como o que a Shopify chamou de Helix.

O desenvolvedor aponta o Helix para uma tela. O Helix lê o código React Native e propõe uma sequência de checkpoints (pequenos segmentos ordenados do trabalho) que podem ser revisados​em minutos. Em seguida, avança checkpoint a checkpoint: cada um deve comprovar seu comportamento por meio de testes, corresponder ao aplicativo em execução em uma revisão visual, passar pelo crivo de dois revisores de código (atuando de forma crítica) e receber a aprovação humana antes de ser consolidado (commit) e de o próximo passo começar. O feedback de cada revisão é armazenado, tornando o processo mais autônomo à medida que a migração avança.

Tem outros pontos interessantes no artigo.

Assim como uma grande empresa usar um framework/biblioteca é bom para essa ferramenta, deixar de usá-la pode ser ruim. No post tem três exemplos de bibliotecas que a Shopify desenvolvia/apoiava e o que vai acontecer com elas. Talvez outras empresas sigam o sinal e saíam de React Native e Flutter também.

Vale destacar, a IA ainda não roubou todos os empregos:

Se você quer ajudar a construir a próxima geração de aplicativos móveis da Shopify, estamos contratando engenheiros mobile, engenheiros de infraestrutura e desenvolvedores que atuam na intersecção entre IA e engenharia de software.

Uso várias ferramentas de IA no dia a dia — Claude, ChatGPT, Cursor, e mais um punhado de outras. Cada uma tem seu próprio limite de uso, que reseta em horários diferentes, e nenhuma delas avisa direito quando você está chegando perto do teto. O jeito que eu ficava sabendo que tinha estourado era o pior possível: no meio de uma tarefa, quando a ferramenta simplesmente parava de responder.

Cansei disso e resolvi criar o Vigia AI: um mostrador que fica sempre ligado na mesa, mostrando o quanto eu já usei de cada conta, sem precisar abrir aba nenhuma nem ficar caçando essa informação escondida em cada app.

A ideia

É bem simples: em vez de descobrir o estouro na hora H, eu já vejo o consumo subindo ao longo do dia, de relance, como quem olha pra um relógio. Dá pra planejar melhor quando usar cada ferramenta, ou simplesmente parar de levar susto.

Como ficou

O projeto cresceu mais do que eu esperava. Hoje ele roda de três formas:

• Um aparelhinho físico, do tamanho de um despertador, com uma telinha touch — fica ali na mesa, sempre ligado.
• Uma versão que roda direto no navegador, pra quem não quer (ou não tem) o aparelho físico.
• Um programa pra instalar no computador (Windows, Mac ou Linux).

Ele acompanha hoje umas 10 ferramentas diferentes (Claude, ChatGPT, Cursor, OpenRouter, DeepSeek, entre outras), aceita várias contas ao mesmo tempo, e ainda manda um aviso no Telegram quando alguma cota está perto de acabar. Também dá pra deixar do jeito que quiser: temas, cores, papel de parede.

Uma preocupação que tive desde o início foi com segurança: o painel só enxerga porcentagens e datas — nunca as senhas ou tokens de acesso das suas contas. Isso fica só no seu computador, do mesmo jeito que já ficava antes.

É de graça e é aberto

O projeto é open source, gratuito, e está todo publicado no GitHub:

https://github.com/TrindadeBRA/vigia-ai

Lá tem instruções de como usar só a parte web (sem precisar montar nada) e também como montar a versão física, se você curtir eletrônica. Se você também vive nesse rolo de usar várias IAs e já levou esse tipo de susto, dá uma conferida — e qualquer sugestão ou contribuição é super bem-vinda.