> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/pt-br/2026/w32-a-builders-mac-also-needs-a-sweeper.md).

# W32-O Mac de um Builder também precisa de um Sweeper

Tenho três Macs. Hoje, minha máquina principal é um Mac Studio de mesa com chip M2 Max, CPU de 12 núcleos e 64 GB de memória, conectado a um monitor 5K e a um microfone Shure MV7+.

Os recursos de hardware são relativamente abundantes. Os gargalos cotidianos vêm mais do ambiente de software. Codex, Claude Code, ChatGPT, Antigravity e Multica ficam abertos em paralelo por longos períodos, iniciando navegadores, servidores MCP, sidecars, máquinas virtuais de sandbox e vários subprocessos. Node, Python, Rust, proxies, Skills, itens de inicialização e caches também mudam continuamente.

A última arrumação começou com um erro pequeno. A tarefa diária de governança de Skills retornou `ModuleNotFoundError: No module named 'tomllib'`. A investigação mostrou que o terminal interativo e a tarefa agendada chamavam Pythons diferentes. No Mac coexistiam o Python do sistema, o do Homebrew, o instalado pelo python.org e o conda. Problemas semelhantes apareciam em Node e Rust.

Ao se acumularem, esses problemas locais tornam o ambiente cada vez menos explicável. Comandos às vezes apontam para versões antigas; a origem de processos em segundo plano fica obscura; uma tarefa funciona no terminal e falha quando agendada. Quanto mais rápido o agente executa, mais rápido o ambiente se desvia.

Hoje, vejo o Mac como o sistema de produção de um Builder. Ele precisa de governança contínua.

### O Builder também precisa assumir o papel de Sweeper

Boris Cherny resumiu recentemente o trabalho da equipe do Claude Code em cinco papéis: Prototyper, Builder, Sweeper, Grower e Maintainer. O Builder transforma protótipos em produtos e infraestrutura prontos para produção. O Sweeper limpa interfaces, simplifica sistemas, remove recursos que perderam valor e otimiza o desempenho. A [publicação original de Boris](https://x.com/bcherny/status/2071379474277613732) mostra combinações de papéis em diferentes estágios de produto. O Sweeper aparece em todos eles.

Isso combina muito com minha experiência recente.

Agentes são naturalmente bons em acrescentar. Podem instalar ferramentas, gerar código, adicionar configurações e criar Skills. O custo marginal de acrescentar já é baixo; remover e consolidar ainda exige julgamento. O que perdeu valor? Quais cópias devem ser unificadas? Qual runtime deve controlar o ponto de entrada definitivo? Que automações podem apagar estados úteis por engano? Essas perguntas precisam de um Sweeper.

Para um Builder individual, o ambiente local também faz parte desse trabalho. Processos, caches, runtimes, configurações de proxy, itens de inicialização, Skills e configurações de agentes são recursos. Têm dependências e se desviam com o uso.

Minha definição de um ambiente limpo tem quatro pontos: os pontos de entrada essenciais têm responsáveis claros; é possível explicar o que está em execução; os desvios podem ser detectados; e o sistema consegue retornar a um estado conhecido.

### Quais recursos existem no Mac?

Minhas principais superfícies de trabalho são Codex, Claude Code, ChatGPT, Antigravity e Multica. No terminal, uso Ghostty e cmux. Na camada de conhecimento, uso principalmente Basic Memory e Craft. O Craft guarda notas, artigos e materiais organizados para leitura humana. O Basic Memory mantém conclusões estáveis, processos reutilizáveis e contexto que os agentes podem consultar continuamente.

A camada de navegação e automação inicia Chrome, Playwright e servidores MCP. Software corporativo de segurança, ferramentas de proxy, métodos de entrada, serviços de sincronização e atualizadores também permanecem ativos.

Um aplicativo de desktop costuma corresponder a um grupo de processos. O Claude Desktop inicia sua própria máquina virtual de sandbox; o Codex inicia um sidecar; navegadores criam processos Renderer e GPU; ferramentas de agentes iniciam subprocessos Node, Python, MCP e de navegador. Observar um único processo no Monitor de Atividade dificilmente explica o consumo real. Minha inspeção agrega processo principal e Helpers por família de aplicativos e, depois, combina `memory_pressure`, swap, incremento de CPU e conexões de rede para avaliar anomalias.

Esses recursos sofrem quatro tipos de desvio.

O primeiro envolve processos e armazenamento. A sessão terminou, mas os subprocessos continuam. Caches de download, logs e artefatos de compilação crescem. O aplicativo hospedeiro também pode reiniciar repetidamente processos que já foram encerrados.

O segundo envolve configuração e rede. Proxy do sistema, ambiente do shell, ambiente de inicialização da GUI, proxy próprio dos aplicativos, DNS e autenticação podem mudar de forma independente.

O terceiro envolve runtimes. Homebrew, instaladores oficiais, gerenciadores de versões e projetos antigos instalam Node, Python ou Rust separadamente. O PATH decide qual vale.

O quarto envolve os recursos de capacidade dos agentes. Ferramentas diferentes instalam Skills em diretórios diferentes; cópias físicas divergem; links simbólicos quebram; a origem recebe atualizações; frontmatter e caminhos fixos começam a falhar.

Os três primeiros afetam a execução estável dos programas. O quarto afeta a capacidade dos agentes de chamar o recurso correto. Todos pertencem ao mesmo problema de governança.

### O proxy é um ambiente em camadas

O ambiente de proxy foi a camada em que passei mais tempo resolvendo problemas.

Há vários caminhos de proxy independentes no macOS. O proxy de rede do sistema afeta aplicativos que consultam as configurações do macOS. Variáveis em `~/.zshrc` afetam apenas o shell atual e seus subprocessos. Processos iniciados pelo Finder, Dock ou aplicativos de desktop costumam herdar o ambiente do `launchd` do usuário. Alguns navegadores e CLIs têm configurações próprias; TUN, DNS e autenticação ficam em outras camadas.

Encontrei um caso típico. O CLI do Antigravity já funcionava no terminal, mas o mesmo runtime no Multica ainda retornava indisponibilidade regional. A primeira correção estava em uma função no `.zshrc`, portanto cobria apenas terminais interativos. O Multica Desktop inicia o daemon pela GUI, sem ler `.zshrc`, e o tráfego acabava saindo diretamente.

A evidência útil veio dos processos em execução. O ambiente do daemon do Multica não tinha variáveis de proxy. Requisições diretas e pelo proxy local também saíam por regiões diferentes. Por fim, coloquei a lógica do proxy em um wrapper no ponto de entrada do executável e simulei uma inicialização não interativa com ambiente limpo para confirmar que o caminho real da chamada havia mudado.

Essa investigação produziu uma regra estável: preciso verificar o processo de destino, não apenas minha impressão sobre a configuração.

A mesma ferramenta pode ser iniciada pelo terminal, por um aplicativo, por uma tarefa agendada, pelo MCP ou por outro agente. O nome é igual; o ambiente de execução pode ser completamente diferente.

### Cada runtime precisa de um único responsável

O erro de `tomllib` acabou revelando quatro instalações de Python. O conda ativava `base` automaticamente, e agentes instalavam pacotes no ambiente global sem que o usuário percebesse. O instalador do python.org escrevia seu próprio PATH em `.zprofile`; o Homebrew mantinha outros Pythons; e tarefas não interativas podiam encontrar primeiro a versão do macOS.

Também havia dois Rusts. O instalado pelo Homebrew vinha antes no PATH, enquanto a versão gerenciada pelo rustup não era atualizada havia muito tempo. No Node, o problema vinha do prefix global do npm. Quando o fnm muda a versão do Node, o diretório de instalação global do npm também muda, mas um wrapper antigo do Claude Code continuava preso a um caminho fixo do Homebrew. A entrada de execução e a de atualização apontavam para lugares diferentes: o comando funcionava, mas não recebia as atualizações corretas.

Depois da limpeza, defini um único responsável para cada um dos três runtimes centrais.

| Runtime | Responsável                                            | Função principal                                                                     |
| ------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------ |
| Node    | [fnm](https://github.com/Schniz/fnm)                   | Gerenciar versões do Node e alternar por projeto                                     |
| Python  | [uv](https://docs.astral.sh/uv/guides/install-python/) | Instalar Python, fixar versões por projeto, criar ambientes e gerenciar dependências |
| Rust    | [rustup](https://rust-lang.github.io/rustup/)          | Gerenciar stable, beta, nightly, versões específicas e componentes                   |

Os runtimes do sistema continuam instalados. Pertencem ao macOS, não entram no meu PATH cotidiano e não recebem dependências de projetos pessoais. Runtimes instalados pelo Homebrew como dependências de outras fórmulas podem continuar como dependências internas, mas não devem tomar o ponto de entrada do usuário.

O Homebrew é adequado para pacotes de sistema, CLIs estáveis, aplicativos GUI e dependências de base, como `ripgrep`, `jq`, `ffmpeg` e os próprios gerenciadores fnm e uv. Se uma ferramenta só precisa da versão estável atual e não exige troca de versão por projeto, ela pode ficar com o Homebrew.

Nos casos abaixo, é melhor usar diretamente fnm, uv ou rustup.

1. Projetos diferentes precisam de versões major ou minor diferentes.
2. O projeto precisa fixar o ambiente com um arquivo de versão.
3. O Rust exige stable, beta, nightly ou uma toolchain de data específica.
4. Pacotes globais do Node mudam de prefix conforme a versão.
5. O Python precisa isolar dependências por projeto, sem contaminar o sistema ou o ambiente global.
6. Agentes, tarefas agendadas e shells não interativos precisam resolver o mesmo ponto de entrada verificável.

Minha regra é simples. O Homebrew gerencia pacotes; gerenciadores de versões cuidam das linguagens; arquivos de projeto definem versões; o PATH expõe uma única entrada padrão.

Antes de remover runtimes antigos, atualizo e verifico o novo responsável. A migração do Rust passou primeiro por testes de compilação, depois pela remoção do Rust do Homebrew. No Python, confirmei primeiro que a entrada padrão do uv funcionava em um ambiente limpo, antes de tratar instalações duplicadas de conda, python.org e Homebrew. Essa ordem evita que a governança comprometa minha capacidade de trabalhar.

### Duas rotinas de governança contínua

Boris também insiste que agentes de longa duração precisam verificar o próprio trabalho. Em tarefas muito longas, um agente em segundo plano pode cuidar da verificação, ou um Stop hook pode executar verificações determinísticas e devolver as falhas ao agente para que continue. Ele considera o retorno da verificação um dos principais meios de melhorar a qualidade e cita, pela experiência, ganhos de duas a três vezes. [Publicação original](https://x.com/bcherny/status/2007179861115511237)

Mais tarde, resumiu a evolução do trabalho como a passagem do código-fonte para agentes e dos agentes para ciclos contínuos. O trabalho humano deixa de ser escrever prompts a cada rodada e passa a ser desenhar ciclos capazes de avançar sozinhos. Na [conversa de Boris no Meta @Scale](https://www.youtube.com/watch?v=Z47vatpsGPI), ele descreve os loops como um salto de importância equivalente.

Um loop eficaz precisa, no mínimo, de objetivo claro, estado atual, retorno de verificação e condição de parada. Após cada rodada, o agente lê os resultados; se a verificação falha, continua; se conclui o objetivo ou alcança um limite de orçamento ou risco, para. O Sweeper dá a direção de reduzir continuamente; Loop Engineering faz isso se repetir.

Criei duas rotinas no Claude para transformar esses princípios em prática diária.

A primeira cuida das Skills todos os dias. Todas as Skills reutilizáveis ficam em uma única fonte de verdade versionada no Git, referenciada por links simbólicos pelo Claude Code e pelo Codex. A rotina corrige automaticamente links quebrados, diretórios vazios que servem apenas de casca, resíduos de cache e links ausentes. Quando encontra cópias físicas, Skills órfãs, erros de frontmatter, atualizações na origem ou riscos de credenciais, apenas analisa e relata. A decisão final fica comigo.

A segunda cuida semanalmente dos recursos básicos do Mac. Primeiro coleta memória, CPU, swap e estado dos processos. Depois agrega os recursos por família de aplicativos e identifica padrões de resíduos já confirmados. Um processo só pode ser encerrado se, ao mesmo tempo, tiver ultrapassado o limite de duração, estiver ocioso em CPU e não tiver sockets de rede. A limpeza de cache cobre apenas conteúdo reconstruível. Dados privados de aplicativos e recursos de origem incerta são apenas medidos e relatados.

As duas rotinas respeitam o mesmo limite. Scripts executam ações determinísticas sem perda de informação; modelos analisam questões que exigem julgamento; pessoas decidem sobre exclusão, sobrescrita e ampliação de permissões.

As descobertas de cada execução também são registradas em Skills, referências e Basic Memory. Na rodada seguinte, o agente lê a fonte de verdade atualizada, e a capacidade de governança se acumula.

### Manter o ambiente limpo é uma capacidade de engenharia

Antes, eu entendia a configuração do Mac como uma tarefa única: instalar programas, configurar shell e proxy e começar a usar.

Hoje, as mudanças são muito mais frequentes. Agentes instalam dependências, iniciam serviços, criam caches, geram Skills e alteram configurações. Node, Python e Rust são atualizados continuamente; aplicativos e CLIs têm cadeias de atualização diferentes; proxies e autenticação se propagam por diferentes caminhos de inicialização.

O Mac precisa de seu próprio plano de controle. Ele deve saber quais recursos essenciais existem, quem cuida deles, qual é o estado desejado, como detectar desvios, quais ações podem ser automáticas e quais decisões exigem parar.

O Sweeper cuida de remover. O loop faz a remoção continuar.

Esse trabalho não produz funcionalidades novas no curto prazo, mas reduz a incerteza de cada execução futura. Agentes deixam de encontrar versões antigas ao acaso; tarefas agendadas e terminais passam a produzir resultados mais consistentes; falhas podem ser localizadas rapidamente em uma camada concreta do ambiente; novas ferramentas sabem a qual ponto de entrada se conectar.

Para o Builder, é um investimento em infraestrutura com retorno acumulativo. Quanto mais estável o ambiente, mais tempo o loop do agente pode rodar. Quanto mais clara a responsabilidade, mais permissões a automação pode receber. Quanto mais completos os registros de governança, menos coisas a próxima investigação precisa redescobrir.

A produtividade futura virá ao mesmo tempo de modelos mais fortes, ferramentas melhores e um ambiente local que permaneça explicável, capaz de convergir para um estado conhecido e governável.

O Builder cria.

O Sweeper impede que os resíduos da própria criação a tornem mais lenta.

### Referências

* [Publicação de Boris Cherny sobre os cinco papéis na equipe do Claude Code](https://x.com/bcherny/status/2071379474277613732)
* [Publicação de Boris Cherny sobre tarefas longas e retorno da verificação](https://x.com/bcherny/status/2007179861115511237)
* [Conversa com Boris Cherny, responsável pelo Claude Code](https://www.youtube.com/watch?v=Z47vatpsGPI)
* [Versões de fórmulas do Homebrew](https://docs.brew.sh/Versions)
* [fnm — Fast Node Manager](https://github.com/Schniz/fnm)
* [Documentação de instalação e gestão do Python no uv](https://docs.astral.sh/uv/guides/install-python/)
* [Documentação de versões do Python no uv](https://docs.astral.sh/uv/concepts/python-versions/)
* [O livro do rustup](https://rust-lang.github.io/rustup/)
* [Documentação de toolchains do rustup](https://rust-lang.github.io/rustup/concepts/toolchains.html)